Table Of ContentDEVSECOPS:
EARLY, EVERYWHERE,
AT SCALE
EXPERT COMMENTARY
ON THE 2017 DEVSECOPS
COMMUNITY SURVEY
eBook
Introduction
In February 2017, Sonatype conducted the DevSecOps Community Survey and over 2,200 IT
professionals participated. The survey revealed that mature development organizations ensure
automated security is woven into their DevOps practice, early, everywhere, and at scale.
Sonatype has invited seven of DevOps and Security professionals to provide expert analysis and
insight of the survey results which are shared in this complementary eBook.
After you have read our expert commentary, we invite you to download the complete set of survey
results at www.sonatype.com/2017survey.
eBook DevSecOps: Early, Everywhere, At Scale 2
TABLE OF CONTENTS
DevSecOps: Embracing Automation, Letting Go of Tradition ............................ 3
DevSecOps: Eat Carrots, Not Cupcakes ............................................................................... 6
DevSecOps: In Time for Security ................................................................................................ 9
DevSecOps: Breaking the Iron Triangle .............................................................................. 12
DevSecOps: Slaying the Myths of Container Security ............................................ 14
DevSecOps: Integrating Automated Security Controls ......................................... 16
DevSecOps: A More Deterministic Approach ................................................................ 18
eBook DevSecOps: Early, Everywhere, At Scale 3
“In a waterfall-native world, traditional
application security approaches are
bolted-on late in the lifecycle,
DevSecOps: Embracing Automation, Letting Go
performed manually, and can take
of Throaurds tiot diaoysn to receive feedback. In
DevOps-native worlds where SDLC
Tyler Shisetladgs,e Vsi cseh Prirneksi dtoe natb, Ssiugrndally S schieonrcte s
windows, old world technologies
TYLERSHIELDS While I awmo na’ltl bfoer atrbaldei ttioo ncsr oliskse tThhea cnhkasgsmivi ningt otu rkey and Sunday afternoon football, holding onto
SIGNAL SCIENCES
this high-velocity realm.”
traditions in your professional life can be career limiting. The awesome thing about careers in tech-
nology is that you constantly have to be on your front foot. Because when you’re not, someone,
somewhere, will be and when you meet them, they’ll win.
One tradition that has a limited lifespan at this moment is waterfall-native development and the
security practices that go along with them. While the beginning of the end might have first been
witnessed when Gene Kim and Josh Corman presented Security is Dead at RSA in 2012, we have
How mature is your adoption of DevOps practices?
26 % 41 % 33 %
have very mature are improving have immature
DevOps practices their maturity. practices
more quantifiable evidence from the 2017 DevSecOps Community Survey. When asked about the
maturity of DevOps practices in their organizations, 40% stated that maturity was improving, while
25% said that it was very mature across the organization or in specific pockets.
In a waterfall-native world, traditional application security approaches are bolted-on late in the
lifecycle, performed manually, and can take hours to days to receive feedback. In DevOps-native
worlds where SDLC stages shrink to absurdly short windows, old world technologies won’t be able
to cross the chasm into this high-velocity realm.
eBook DevSecOps: Early, Everywhere, At Scale 4
For those of us in the security profession, there is an awesome opportunity in front of us. Our
of security respondents are in agreement that security is seen as an inhibitor to DevOps agility
brothers and sisters in the Dev and Ops realms are calling on us to innovate.
(Q31). It feels as if we may be letting the opportunity to drastically fix our application security
woes pass us by.
Source: 2017 DevSecOps Community Survey
Moving from an inhibitor to an enabler of best practices requires a mindshift. The solution to
Moving from an inhibitor to an enabler of best practices requires a mindshift. The solution to these
these difficulties is security automation at the speed of DevOps. Successful application security
difficulties is security automation at the speed of DevOps. Successful application security has been
has been defined as increased automation that doesn’t slow down the development and
defined as increased automation that doesn’t slow down the development and operations process.
operations process. Imagine a scenario where developers embrace security rather than find
Imagine a scenario where developers embrace security rather than find ways to work around it.
ways to work around it.
When the cycle times shrink, it’s time to rethink how we continue to refine and improve application
When the cycle times shrink, it’s time to rethink how we continue to refine and improve
security. As enterprises adopt and enhance DevOps, application security teams should focus on
application security. As enterprises adopt and enhance DevOps, application security teams
decreasing the amount of time it takes to detect an attack in progress and respond to an identified
should focus on decreasing the amount of time it takes to detect an attack in progress and
issue. In a DevOps native world, automation of attack, anomaly, and application security protection
respond to an identified issue. In a DevOps native world, automation of attack, anomaly, and
at runtime are paramount. Hanging on to traditions is non-essential.
application security protection at runtime is paramount. Hanging on to traditions is
non-essential.O ne example of where DevOps and Security are sprinting at the same pace is with runtime appli-
cation self protection (RASP) and next generation web application firewall (NGWAF) technologies.
One example RoAf SwPh aenred NDGeWvOApFs t eacnhdn oSloegciuesri tayll oawre e snpterirnptriinsegs a vti stihbeili tsya inmtoe appapcliec aisti owni tshe cruurnittyim ateta cks and
application seldf aptaro atte rcutniotinm (eR, gAiSvinPg) saencdu rnitey,x ot pgeernaetiorantsi,o ann wd edbev aeplopplimcaentiot tne afimresw aa cllh (aNncGeW toA iFm)p rove applica-
technologies. t iRonA SsePc uarnityd rNesGuWlts AbFey toencdh njuoslto ingcieresa asellodw sp eenetde ropf raissesess vsmiseibnitli.t By yin tatok inagp pthliec aretisounlt s of runtime
security attacksse caunrdity d vaistaib ialitty r uanndti mpreo tgeicvtiinogn asnedc ufereityd,in ogp tehraat tiinofnosrm, aatniodn d beavcekl oinptom aelln stt ategaems osf ath e develop-
chance to improve application security results beyond just increased speed of assessment. By
taking the results of runtime security visibility and protection and feeding that information back
eBook DevSecOps: Early, Everywhere, At Scale 5
ment cycle we are able to increase velocity while simultaneously increasing the security of our
entire development effort.
DevOps practitioners will lead the charge to implement new application security technologies that
meet these requirements, moving beyond traditional WAF deployments to modern application
security technologies that embed into the heart of the application itself. The closer the protec-
tion gets to the core of the application, the stronger and more accurate the results. Automation is
one of the fundamental keys to DevOps success, and security can’t be overlooked. Automation
of application security will democratize security data, breaking down silos between groups while
helping the entire organization operate more efficiently.
We can always just stick to tradition. Stick to what we have held to be absolute truths in applica-
tion security for the last decade. Or we can choose to innovate our application security practices
to incorporate learnings from the changes that are occurring around us. I think it’s pretty clear that
innovation is required if we are to properly secure the modern application environment, and that
innovation will come in the form of application security automation.
eBook DevSecOps: Early, Everywhere, At Scale 6
“Confirmed or suspected breaches
related to vulnerable open source
components doubled from 2014 to
Dev20S17e. cOps: Eat Carrots, Not Cupcakes
Yet, during the same period, the
Derek E. Weeks, Vice President, Sonatype
percentage of organizations
You gAorveer nWingh tahet uYsoe uof sEeacutr.e
DEREK WEEKS components remained the same.”
SONATYPE
When it comes to food, we all know what’s considered “good” and what’s “bad”.
For fried, battered, buttery or creamy: the category of cupcakes and such...just say no. When
fresh, grilled, steamed or baked: of course, you should eat your veggies and other fine foods...bon
appetite.
We can all understand this simple rule when eating. But for many, when it comes to software de-
velopment, simple rules and advice from nutritional labels aren’t always there for us. Simple rules
like, use “good” open source components, not “bad” ones (i.e., vulnerable, outdated, risky licens-
es) when building and deploying your next app.
Evidence of Gluttony.
To meet the need for speed, virtually all modern development organizations are using open source
and third party components to assemble applications rather than build every function from scratch.
According to the 2016 State of the Software Supply Chain report, the average development orga-
nization feasts on over 229,000 open source Java components each year, but we’re seeing similar
consumption practices in the JavaScript, Python, Ruby, and .NET development realms. While the
upside of this gluttony is improved productivity, there is a downside to consuming components
without the proper insight into their quality.
Beyond the consumption of open source and third-party software components in development, the
same guidance holds true for containers used by DevOps teams. Today, over 100,000 free apps
are available on Docker Hub, and consumption of those applications into DevOps tool chains and
infrastructure often goes unchecked.
The Downside of Efficiency.
While sourcing components and containers can accelerate development efforts, many organi-
zations do not apply sufficient scrutiny to assessing their quality or security. The 2016 Software
Supply Chain report also indicates that 1 in 15 of the components used in applications contain at
least one known security vulnerability. What this means is that not all components and containers
are created equal. It also means that blind consumption practices can have both immediate and
long-term consequences for the organization consuming the open source software components or
containerized applications.
eBook DevSecOps: Early, Everywhere, At Scale 7
According to the 2017 DevSecOps Community survey, 57% of organizations looking to improve
the quality of components used in their development practices have implemented an open source
governance practice. This is up only slightly from the 2014 survey which showed 57% of organi-
zations with open source policies in place. For those without a policy, there are no rules in place
when it comes to “good” vs. “bad” consumption practices. Having policies in place can help to
improve the quality of applications being produced, reduce vulnerabilities to attack, and eliminate
use of components with risky license types.
57%
Source: 2014 Sonatype Open Source Development and Application Security Survey, and Sonatype’s 2017 DevSecOps Community survey
Breaking Bad.
Breaking bad. To furtheAtr tehem tipmhea, osvizeer 2 t,7h0e0 nsuerevedy fpoarr teicvipaalnutsa itnindigc acteodm thpaot nmeornet tqhauna 1l iitny 1 0a nordg asneizcautiorintys ,(1 4le%t)’ sh atda ke a
look at one of the findingesx pfreorimen coeudr o 2r 0su1s4p escuterdv ea yb.r e aActh tihn athte tiirm apep,l iocavteiorn s3 r,e3la3t0ed s tuo ravne oyp epna srotiucricpea snotfstw ianred iccoamte- d that 1
ponent. Because, that survey took place in the same month that the notorious OpenSSL software
in 10 organizations had experienced or suspected a breach in their applications related to an open source
component (a.k.a“Heartbleed”) vulnerability was announced, I felt like it might have inflated the
software component. Because, that survey took place in the same month that the notorious OpenSSL
number of breach related responses. To my surprise, the 2017 survey shows that 20% of organi-
software component (a.k.a“Heartbleed”) vulnerability was announced, I felt like it might have inflated the
zations (1 in 5) had or suspected a breach related to open source software components in their
number of breach related responses. To my surprise, the 2017 survey shows that 20% (1 in 5)
applications. In the past three years, as the rate of confirmed or suspected breaches related to
organizations had or susvpuelncetreadbl ea o bpreen ascouhr cree claotmepdo ntoen otsp iencnre saoseudr cbey 5s0o%ft, wthae rneu mcobemr opfo onrgeanntisza itnio ntsh ehairv iangp prulliecsa tions.
In the past three years, ains ptlhaece r taot geo ovef rcn othnef iursme eodf s oecru sreu csopmepcotneedn tbs rreemacaihneeds trheel asatmede. to vulnerable open source
components doubled, the percentage of organizations having rules in place to govern the use of secure
components remained the same.
eBook DevSecOps: Early, Everywhere, At Scale 8
Across the DevOps community, we are seeing much more attention being paid to security concerns and
more organizations finding news ways to automate practices early in the SDLC. Automating the evaluation
of open source and third party components against rules designated in open source governance policies is
Breaking bad. To further emphasize the need for evaluating component quality and security, let’s take a
look at one of the findings from our 2014 survey. At that time, over 3,330 survey participants indicated that 1
in 10 organizations had experienced or suspected a breach in their applications related to an open source
software component. Because, that survey took place in the same month that the notorious OpenSSL
software component (a.k.a“Heartbleed”) vulnerability was announced, I felt like it might have inflated the
number of breach related responses. To my surprise, the 2017 survey shows that 20% (1 in 5)
organizations had or suspected a breach related to open source software components in their applications.
In the past three years, as the rate of confirmed or suspected breaches related to vulnerable open source
components doubled, the percentage of organizations having rules in place to govern the use of secure
components remained the same.
Across the DevOps community, we are seeing much more attention being paid to security concerns and
more organizations finding news ways to automate practices early in the SDLC. Automating the evaluation
Across the DevOps community, we are seeing much more attention being paid to security con-
of open source and third party components against rules designated in open source governance policies is
cerns and more organizations finding news ways to automate practices early in the SDLC. Auto-
mating the evaluation of open source and third party components against rules designated in open
source governance policies is one the approaches being adopted. While not the only answer to
DevSecOps requirements, having an automated policy in place to enforce governance and guide
remediation can pay off handsomely if it also helps prevent a breach.
When it comes to carrots and cupcakes, the right choices can offer great short- and long-term
benefits. In the realm of components and containers, making “good” choices will also benefit your
DevSecOps practice.
eBook DevSecOps: Early, Everywhere, At Scale 9
DevSecOps: In Time for Security
DevSecOps: In Time for Security
Hasan Yasar, Technical Manager and Adjunct Faculty Member
CHaarsnaeng Yiea Msaerl,l oTne cUhnnivicearls Mitya nager and Adjunct Faculty Member
Carnegie Mellon University
“The inability to anticipate attacks is
why we often see patches coming
Changing Mindsets. Hisotuot irni creaslployn sed teov neewlo0p-dearys have prioritized functional requirements over
vulnerabilities. DevSecOps
sCehcaunrigtyin wgh eMni bnudisldeintsgD. sHoefivtsdwteSovaereriloecpca.e lOrlsWy w phoduisllede: v r aseItehnloecr p utThereeriirsm c ohedai vnfego prpr raSiocetriictciezuse rdimi tfpyuonrctatinotn, athl erye qhuaivreem oeftnetns faolvleenr
software absorb the attacks and
isnetocu sreityc ownhdeanry b ouri ldteinrtgia sryo frtewqauriere. mWehnitlse fsoerc tueraem cso dbiunigld ipnrga catpicpelisc aimtiopnosrt aangta, itnhset ya h daevaed olifnteen. fallen
Hasan Ycaosnatri,n Tueech tnoi cfauln Mctainoang. eInr aontdh eArd wjuonrcdt sF,a culty Member, Carnegie Mellon University
i nto secondary or tertiary riet sqhuouirlde bmenedn btust nfootr b treeaak.m Thsis building applications against a deadline.
Chanshgifti nin gth iMnkiinng dfrosme at sp.revent to a
"SoftwarHeAS AsNe YcASuARrity" often evokes negative feelings among software developers because it has
bend-don't-break mindset allows for
CARNEGIE MELLON
a lot more flexibility when it comes
b"Seoefntw aasrseo csieacteudri tyw"i thof taednd ietivoonkael sp rnoeggraamtivme infege elinffgosrt ,a umnocnegrt asionfttyw aanred droeavdeblolopcekrss tbheacta huinsed eitr hfaasst
Historically, developers have prioritized functional requirements over security when building
to dealing with attacks.”
bdeeevenl oapsmsoecniat taendd w ritehle saoafdtswdeai rteico. ynWcahliell esp s.re ocLugraer taceomldyimn, gi tnphrgaac tte icmfefso ianrrted, ismuepntoc rtehanratt,sa t hinebytey he aavnen odcf thernao nfaagldleibnn ligont coi knses c lotahnrdagater yh opirn adret ra fsa sat
tertiary requirements for teams building applications against a deadline.
dreesvuellto opfm seuncct easnsdfu lr ealdeoapsteio ncy ocfl easu.t oLmataetleyd, stheactu rmityin idnstoe tD heavsO pbse epnra ccthicaensg.i ng in large part as a
r esult of successful ad"Soopfttwioarne soefc uariutyt" oomftena etevodk esse nceguartiivtye fienetliong Ds aemvoOngp ssof tpwraarec dteicveelsop. ers because it has
The DevSecOps Combmeenu ansistoyc iastuedr vweithy a dredivtioenaall eprdog rtahmamt in2g4 e%ffor to, ufn caelrlt apinatyr atincdi proaandbtlso cbkse tlhiaet vhein diesr fnasot w a top
development and release cycles. Lately, that mindset has been changing in large part as a result of
Tcohnec eDrenv Sfeocr Odpes vCeloompemrsu.n itHy oswuervveeyr, reinv eaolregda nthizaat ti2o4n%s owfi tahl l psaerlft-icdiepsacnrtisb ebde liemvaet uisre n oDwe vaO topps
successful adoption of automated security into DevOps practices.
pcoranccteicrens , f3o8r %d eovf erelosppeornsd. eHntosw setavteerd, tihna t osregcaunriiztya twioanss aw toitph csoenlcf-edrens acrnibde tdh atm thaetuirr ed evDeelovpOeprss
The DevSecOps Community survey revealed that 24% of all participants believe what is now a top
sppraecntdic eas l,o 3t 8o%f t iomf er eosnp iot.n dTehnists m setaatnesd tthhaat t sseeccuurirtiyty p wraacst icae tso pin cdoenvceelornp manedn tt hhaatv eth aei r6 0d%ev eglroepaetersr
concern for developers. However, in organizations with self-described mature DevOps practices,
sapdeonpdtio an lroatt eo fi nti mDee voOnp its. tTeahmis sm. eans that security practices in development have a 60% greater
38% of respondents stated that security was a top concern and that their developers spend a lot of
a doption rate in DevOtpimse toen ait.m Tshi.s means that security practices in development have a 60% greater adoption rate in
DevOps teams.
The overall survey results also revealed that 67% of developers didn’t have enough time to
s Tpehned o ovne rsaellc usurirtyv eoyr brTeehseliu eolvvteser adall slistu rotvoe y rb ereevs eutlhatsel ae lsdroe rstehpvaeoatnl e6sd i7tbh%ailti t 6yo7 %fo ofd f oedetvhveeelloorpspe.er s r dsid nd’ti dhanv’et ehnoauvgeh tiemne otou sgpehn dt ime to
s pend on security or boen lsieecvueritdy oitr btoel iebveed t iht teo bree tshpe orenspsoibnsiilbitilyity o off ooththeres.r s.
Source: 2017 DevSecOps Community Survey
eBook DevSecOps: Early, Everywhere, At Scale 10
Description:SDLC stages shrink to absurdly short windows, old world technologies won't be able to cross the chasm into this high-velocity realm. are available on Docker Hub, and consumption of those applications into DevOps tool chains and infrastructure often goes unchecked. The Downside of Efficiency.
