devopsy.kinsta.cloud

Category: DevSecOps

DevSecOps: Embedding a Security Practice into your DevOps Approach

It’s a no-brainer that the element of security cannot be compromised even to the smallest of extents in today’s competitive, fast-paced, modern technology-driven IT infrastructure. However, to keep up with the rapid developments of other processes in this agile world, security is often given relatively less importance and in some cases, even left behind. As the term suggests, DevSecOps is primarily concerned with the incorporation of security in the DevOps pipeline.

The intended primary function of DevSecOps is to help overcome the aforementioned barrier by extending the conventional framework of DevOps and inculcating security testing by means of various security tools. This article attempts to explore the significance, characteristics, benefits and challenges involved in DevSecOps implementation and practice.

Why DevSecOps Matters

Since the rate of cybercrime over the past few years has been increasing at a significantly high rate, the need for adoption and implementation of DevSecOps is also intensifying. An analytical study from Cybersecurity Ventures predicts that the damages incurred from cybercrime will be as high as $6 trillion annually by the year 2021, double the $3 trillion in 2015. As the benefits reaped from implementation are linked directly to the reduction in cyberattacks, DevSecOps is becoming the center of attention of IT decision-makers.

Breaking Down DevSecOps

The following factors constitute the core of the DevSecOps approach and are the key to a successful implementation:

Automation

While the concept of DevOps revolves around automating the build, test and deployment sections, DevSecOps additionally focuses on automating security. Automation is crucial as the security—besides being able to be scrupulous and comprehensive—also has to catch up with the much faster release cycles driven by DevOps. The target of DevSecOps is automating all of the security controls, thus eliminating the need for manual interference.

People, Process and Technology

The trio of people, process and technology is the pillar and it directly influences the extent of success of any DevSecOps approach and practice. The People—considered as the weakest link of the three—are the security specialists and integration of the security team with the development team. Appointing “security champions” who form a cross-functional team to work on the application security, is a key element of the People practice. The Process involves standardizing the workflow, documentation and execution of the same to make sure that the security is transparent with other processes in the workflow. The Technology refers to the various facets deployed in DevSecOps such as the automated vulnerability management, automated compliance scan, etc., whose applications are directly involved in the implementation.

Different Tools for Different Functions

There are a number of security tools that specialize in various aspects of the DevSecOps approach, including testing, secrets management, attack modeling and red team. Selecting the right tool for the right function is paramount and it is not always easy since many of them are still in the emerging phase.

With DevSecOps, You Get …

Enhanced overall security: The overall security of the infrastructure is strengthened by identifying and reducing vulnerabilities as and when they occur. In case some minor breaches happen, the rate at which the recovery happens is also escalated.

Total Cost Reduction: Unlike the conventional approach, in DevSecOps the security issues are identified and dealt with in the development phase itself. Consequently, this leads to reduced overall costs incurred in the development and security of applications.

Accelerated delivery speed: The implementation of DevSecOps consistently strives to detect and eliminate the security bottlenecks at various stages of development. This, in turn, increases the speed at which the product is delivered.

Besides the above-mentioned benefits, DevSecOps also nurtures an environment of transparency and helps in increasing the customer value.

But, Implemention is not a Piece of Cake

Comprehensibly, there are many challenges that lie ahead before DevSecOps implementation. The availability of sufficiently skilled cybersecurity professionals is one of them. This is because the extent of expertise needed in cybersecurity is underrated when compared to other business units. Unlike the traditional environment, a DevSecOps methodology means that the various internal teams of the business unit such as the development and security teams need to work in unison, which might not always go smoothly. The fact that building secure code is time-consuming can frustrate developers, as it hampers their speed of delivery. Many mid- and low-level organizations are skeptical about security as, economically, it is viewed as more of a liability rather than an asset.

In my next article, I will be applying a templated approach to shortlist tools that would be suitable for your organizational needs. For illustration, a series of webinars that cover the various aspects of implementation of DevOps can be found here.

According to the WhiteHat Security Application Statistics Report, “The average customer takes 174 days to fix a vulnerability found when using dynamic analysis in production. However, those who have implemented DevSecOps do it in just 92 days. If we look at vulnerabilities found in development using static analysis, an average company takes 113 days, while the DevSecOps companies take just 51 days.” It is evident that, in the long run, the benefits reaped from DevSecOps outweigh the challenges. A successful approach drastically reduces the chances of succumbing to cybercrimes while being agile and revolving around the mindset, “Everyone is responsible for security.”

— Kavin Elango

June 14, 2018
DevOps Chat: Post-DOES Workshop w/ Gary Gruver & Helen Beal

Gene Kim’s DevOps Enterprise Summit UK is just a few weeks away, June 25-26. While DOES UK this year is shaping up to be a must-see event, there are also some great events taking place around DOES. One is sponsored by Electric Cloud (also a founding sponsor of DOES). It is a post-DOES workshop, featuring classes taught by Gary Gruver, John Willis and Helen Beal.

The workshop session lineup includes “DevSecOps,” by John Willis, “Leading the DeOps Transformation,” by Gary Gruver and “DevOps Essentials,” with Helen Beal. Helen’s DevOps essentials and Gary’s executive leader workshops are both half-days, so you can attend both. Each of these are great learning events as well as a great way to network with your peers. If you are in London on June 27, be sure to check them out.

As usual, immediately below is the streaming audio of our conversation, followed by a transcript so you can follow along.

Audio

Transcript

Alan Shimel: Hey everyone, it’s Alan Shimel and you’re listening to a special edition of DevOps Chat. We have three folks on our panel for DevOps Chat today, and each one of them, actually, are really kind of special people to me within the DevOps community. And let me introduce them to you right off. First and foremost, ladies first.

I want to introduce Helen Beal. Helen of course is DevOps fantastic at Ranger Four. But also, Helen was one of the first people I met in the DevOps community over in London and has been a friend ever since. Also has a position with the DevOps institute – an advisory role at DevOps institute as well. So Helen, welcome to DevOps cChat.

Helen Beal: Thank you very much, it’s a pleasure to be here as always talking to you.

Shimel: Thank you. My second guest really needs to introduction in the DevOps community. He has three – count them, one, two, three books around DevOps as well as many years of leading DevOps teams at HP and Macy’s and now consulting for many, many different organizations and helping them with their digital transformations and DevOps journeys, none other than Gary Gruver. Gary, welcome.

Gary Gruver: Hi, thanks great to be here, nice to be speaking with you again.

Shimel: Nice to have you here. And then certainly, last but not least – one of my good friends in the DevOps world, he runs marketing at Electric Cloud, which is also of course the founding partner of the DevOps enterprise summit (DOES) with Gene Kim and ITREV– Sam Fell. Sam, welcome.

Sam Fell: Thank you, Alan. Happy to be here.

Shimel: Okay, first thing I want to talk about today is we’re getting close to DOES London, which I believe is what? June 25 and 25 over at the O2 in London.

And I know you’ll all be attending there and of course we can – Electric Cloud is again one of the founding sponsors and we can get all that information over on the IT revolution site. But part and parcel with Does London this year, I wanted to mention two special events taking place on the heels of Does London.

One is a special post-Does workshop which, Sam, you and the Electric Cloud folks have driven. Why don’t you give us a little background here on what you guys are doing and why?

Fell: Yeah, great – thanks, Alan, I appreciate that. So Gary – you mentioned, he has had all this experience helping these large companies with their digital transformations. When we started our user conference back in 2013, Gene Kim came and spoke, Jez Humble came and spoke.

And we were talking together, we said these are exactly the kind of people – these old horses that are trying to do these transformations that we want to try and attract to a large conference, which is sort of what the genesis of the DevOps enterprise summit. The folks that show up at that show, a lot of them are in a tough spot.

They know they need to transform. Their business wants them to transform, they don’t know how to go about doing it. And so having a community of people that are available to talk to and learn from, admit mistakes to in a safe way, to know that you’re gonna get advice and counsel, it’s a fantastic show that the team has put together. And you can see by the success of it that the community really embraces it.

So our thought last year with Gary was why don’t we take somebody who has helped companies with these transformations and go to DevOps enterprise summit and listen to those stories and see what people are going through and then directly after that you get in a room with an expert coach who can say, now, let’s apply that to you. Let’s apply that to your situation. All those stories that you’ve heard, how does that work for you?

And last year we had just a fantastic time and so we decided to do the same thing this year at Does London. We’ll be doing the same thing at Does Los Vegas in October as well. And it’s just an opportunity for people to really put in practice and make real a lot of the things that they heard at the fantastic DevOps Enterprise Summit.

Shimel: Fantastic, Sam. And it is, it’s a great workshop. Gary and Helen – before I jump over to you, Sam – I forget I apologize. For people to register for the workshop, what’s the cause? What’s involved? Where do they go?

Fell: So it’s a heavily subsidized workshop. Helen, the DevOps institute, Gary, John Willis – these guys are giving their time in order to provide this for the community. Electric Cloud is helping to pay for the room and all this other stuff. So the cost is pretty minimal. I think it’s £195.00 for our early bird.

We don’t have that many tickets eft but there are some tickets. There’s a group rate as well. So you know, non-expensive and it’s an opportunity for you to really rub elbows with people who are always wanting to learn how to do these types of things. And as you mentioned, John, we do have these couple different workshops.

John Willis is doing Dev-Sec-Ops hands on technical workshop that same day. So we’ve got two tracks that we’ve got set up basically. I don’t want to spill the beans on what Helen and Gary are going to be talking about, but the John Willis workshop we’re really excited about that. He’s gonna be showing people with a live pipeline how to incrementally improve it. how to bake security into your deployment pipelines.

And one of the types of things that you can do to enable your teams and your developers to ship secure codes. Fantastic stuff.

Shimel: Yeah, no, that’s gonna be a great hands on workshop for anyone interested in DevSecOps. We’ll have more info about DevSecOps in a little bit. But first, let’s turn to Gary. Gary – what is your workshop going to be about here?

Gruver: I think I’m gonna follow your lead. Let’s go with Helen’s first with lady’s first and get to that and I think that’s the order that we’re going in with the day. Why don’t you lead off with Helen and then I’ll follow up.

Shimel: Chivalry is not dead. Helen – go ahead.

Beal: Thanks, Gary. So I’m going to be doing the half day DevOps institute course – the essentials of DevOps which essentially kind of what it says on the tin, the fundamentals or the foundation and relevance of DevOps and things like the three ways and coms and how it fits with Agile and IT send and Lean, PK studies, linking it to this integration.

And continuous delivery. How they lead from one another. So that’s it. It’s a course really for people that are quite new to DevOps and they should expect to leave the course, really with an understanding of where DevOps has come from, why it’s important and what sort of business benefits people can anticipate from using DevOps practice and principles.

Understanding some of the vocabulary that those of us that kind of live and breathe DevOps are quite familiar with. So things like the theory of constraints and CD and things like that and hopefully with some kind of action plan of what they can take back to their desk the next day and start making some DevOps differences in their own organization.

Shimel: And it is the DevOps essentials course it’s really sort of a big time version of the full DevOps foundation, which Helen – you were instrumental in refreshing for this latest– I think it’s released three of DevOps foundation?

Beal: Yeah, it’s very nearly ready. So it’s been updated with lots of additional case studies, we’ve updated things like the surveys too, the latest versions of the state of DevOps surveys. I know there’s another one coming out. I don’t think we’re expecting it for another few months, and actually part of what we’ve been doing this update is following our own principles. So we’re actually aiming for a much more incremental release cycle as we move forwards rather than in frequent big updates.

I’m sure we’ll all be on board with that. And then, newer things have been coming through like liability engineering and more stuff around services and containers and those sort of things. Focused on safety culture, learning organizations and some of the things that John and Gene can cover in their beyond the finished product audiobook, also featured in there.

As is some of the material from Nicole’s and Jane’s book – accelerate. And some references to that. And then we’ve removed some of the stuff that kind of isn’t really around anymore in the DevOps World.

So things like NoOps – think it’s really gone away now. Rocket DevOps has been very overtaken by DevSecOps. So it’s a good solid refresh and hopefully the foundation will be able to keep refreshing it more frequently as this is such a fast changing world that we’re in – this DevOps world.

Shimel: It certainly is. Okay, that’s fantastic Helen. And I encourage listeners that may be in the London area that week, if you’re near to DevOps or you really haven’t taken any formal DevOps sort of education or classes, you know, listening – goes to Does is a great way to learn from real life examples. But really this is a great class to give you a nice foundation in DevOps. Gary, how about you?

Gruver: I’ll be doing my executive workshop that I do with most organizations when I go in and work with the executives to really help people put together their plans and figure out how do they approach it. The people that are gonna be at. Does are gonna be hearing a lot of different ideas, and a lot of perspectives on what they should be doing and I’ll hopefully be trying to help them put that in context.

My big thing I champion is there are different approaches you need to use when you’ve got large tightly coupled systems than you do when you have small teams that can independently develop and qualify and deploy code. We’ll be going through a lot of those differences. We’ll be going through the role of the executive in terms of leading the transformation.

A lot of this can be empowered if you have loosely coupled small teams but if you’ve got large groups of people who have to work together to coordinate the deployment pipeline in terms of being able to develop, qualify and release as a system, then you need to have the executives playing a pretty active role in coordinating the work across those teams and prioritizing the improvement. So we’ll be going through that.

How do executives get the team all on the same page? And then how do you get them to a common definition of what they’re gonna go do and agree to that? So my analogy is a pipeline ____ described an elephant feels like most discussions I start with organizations that are starting to go down their DevOps transformation.

And what I work to is a process and approach to give them a common view of the elephant and get people all rowing in the same direction. And helping people understand that the types of things they can and should do are different for large, tightly coupled systems versus loosely coupled systems. And then we’ll go through and we’ll help them understand where they should really be starting their transformation.

Which is different for a lot of different organizations. And I feel that starting point is really important, because this is a lot of energy. It’s gonna take a lot of effort to transform how you do software development.

And you really want to pick the changes that are gonna have the biggest impact on your business first off so you can create that positive momentum. I think if you just go down the path of doing DevOps without picking those things that will have the biggest impact, you’ll start doing it, you won’t see the benefits, and over time the organization will kind of disengage and you’ll lose momentum on your transformation.

So a lot of what we focus on is trying to highlight those key lynchpins that you can really start making the big differences and how to go analyze that for different deployment pipelines in your organization.

So it’s really that. I’ll be there. But there will also be a lot of your peers in the room. So it’ll be a good opportunity to take the things that you learned at Does to reflect on them and talk with myself and your peers about what you’re thinking about doing.

And learning from it. And I would say that I’ve been doing this for a long time, and what I tell people is that just gives me more opportunities to have made the mistakes that you’re gonna make.

And so if I can help you avoid the mistakes I already made so you can go make some new ones, learn from that, that’s kind of my goal. My experience is this stuff is such a breakthrough for the business that we’ve gotta have more people doing it. But how can we help people best we can so they realize those same benefits.

Shimel: Excellent. Gary – you know, one of the things I think sometimes people get confused or question is when we talk about this is aimed at executives. It’s sort of a loaded term. In a large organization like a Macy’s, executive might mean CIO, it might mean VP of IT. in other organizations it may mean a director level. Can you give us a better definition or how you define you know, the executive who is gonna get a lot of good out of this workshop?

Gruver: I think they all will. I’ve done it all the way from the CIO and I do execution workshops down to – to the leaders that are responsible for a tightly coupled deployment pipeline and then some organizations that might be a director or senior manager that’s over development and ideally, it’s nice that you can bring your partners in QA if it’s separate, and in operations if it’s separate. Maybe your security people, maybe your audit people.

And come together as a team after Does. So if you’ve got a group of people that have gone to it and gone to a lot of different presentations, having them come together on that will be helpful. So this is the group at whatever level in the organization you think will be leading the transformation, or driving the changes. It can be – typically the CIO when I do the executive workshop is more to inform them of their role in it. Then at some level, we get down to a specific deployment pipeline.

And the deployment pipeline may still be 1000 people if you’ve got a large tightly coupled system, like we had at Macy’s.

Which requires large numbers of people working together, or it may be small. And if it’s small, you can do a lot of the things that you’ve seen unicorns do. And if it’s larger, the same principles apply but the practices are a little bit different.

Shimel: Excellent. Yup. Great. So guys, we’ve covered a lot of ground here. Let me do a quick review. Sam, what day is the workshop?

Fell: The workshop is the day directly after DevOps enterprise summit. Wednesday June 27.

Shimel: It’s June 27.

Fell: That’s correct. Right before… DevSecOps days on the 28^th!

Shimel: Yes, and Sam – I will put in our show notes a link to the URL about the workshop and registration. But where is it being held specifically?

Fell: It’s conveniently located in exactly the same location as the DevOps Enterprise Summit which is the InterContinental – O2 in London. So if you’re in London, very convenient area to get to also. So come on by.

Shimel: Excellent.

Gruver: And you don’t have to have gone to DOES or the DevSecOps. If you’re in Europe and you wanted to stop by.

Shimel: Excellent point. It’s not a pre-req if you’re looking for some good, hands on DevOps training and networking and education, this workshop is a standalone event. It’s fantastic as well. So let’s cover the three different workshops actually being conducted that day though. Number one is we’ve got none other than John Willis himself leading a real hands-on DevSecOps. Is Anders working with John on that one, Sam?

Fell: Anders will be in there, yeah, he’ll be hanging around. But this is really John’s show. And this is his passion. And he’s driving the technical aspects of this workshop where people are really gonna be able to get their hands dirty with the technology, have a pipeline. Put some vulnerable code through it, and deploy it and then figure out how do we put automated steps in place and how do we sort of put the – get the developers thinking the right way to make sure that that kind of stuff can happen and what are the practices that need to be put in place. So really, for folks who want to try and get that level of specificity of how to do it, not just the high level, interesting, interesting workshop for people.

Shimel: Absolutely. We’re all hearing a lot about DevSecOps. Gary made reference to DevSecOps. I think Helen did as well. And we talk about this DevSecOps rugged DevOps etc. This is really gonna be hands on. so it’s great whether you’re a DevOps person or a security person. Then we have Helen who is delivering the pre-req 101 DevOps essentials, based on the latest upcoming version of DevOps foundation from the DevOps Institute. And Helen, people who take essentials – do they get any kind of credit or anything towards a foundation or being able to take a certification or anything like that?

Beal: As you said earlier, it’s basically a cut down version of the DevOps foundation course and that’s a certified course. This isn’t a certified course, so I’m sure if people wanted to follow up with the DevOps foundation, we could sort something out.

Shimel: Fantastic. And then certainly, last but not least, aimed at DevOps leaders and executives, Gary is gonna be in essence, delivering what many organizations are paying thousands and thousands of dollars for. His course on kind of leading the transformation. That’s taken right from one of your books, Gary. I apologize. But really, dollar for dollar, what a great line up, what a great deal for anyone who is looking for DevOps training and education. I also wanted to quickly before we run out of time here, I wanted to mention that the day after the workshop is the first DevSecOps days in London.

Again, headlined with John Willis. I think, Helen, you’re speaking there as well. Correct?

Beal: I am, indeed. Yes.

Shimel: Give us a little preview, what are you talking about?

Beal: So John saw a talk I think I did in Belfast or somewhere – maybe last year. It might have been all day DevOps, can’t remember. Anyway. But basically we’ll be talking about DevSecOps engineering as a concept. As you probably know, the DOI at DevOps institute is just about to release a new course for DevSecOps engineering. So we’ll be talking about that role and what the requirements are to be successful in that area.

Shimel: Yup. And DevSecOps days also promises to be a fantastic day. Sam and the Electric Cloud folks – we’re grateful for your sponsorship. Electric Cloud is one of the sponsors there. I will put in the show notes where you can get more information on DevSecOps days as well. But you can go to DevSecOpsdays.com and that’s the long and short of it right there. Guys, a couple of minutes left, let’s wrap up.

Helen – beyond all of the great stuff you’re doing with DevOps institute, what any good news? Any new things going on with Ranger Four?

Beal: One of the nice popular things that we’re doing at the moment is one of my favorite things conveniently as well. Which is our version of Phoenix project simulation game. That we kind of developed with our partner Gaming Works out in Amsterdam. So it’s a one day business simulation so experiential learning rather than classroom learning. We’ve got a free, public version of that coming up in London on the 19^th of July. It is quite close to being fully booked.

But if people want to find me on Linked In or would like to come along, we do have a couple of spaces left.

Shimel: Excellent. And I’ve done the Phoenix Project simulation game, I love it and I’m sure you guys will deliver a rousing version, highly recommend. Gary, how about you?

Gruver: Oh, I’m just spending more of my time with individual companies, learning from their journeys and trying to help them avoid the mistakes I’ve made and help them to learn from new mistakes they’re finding so I can help point it out to other people so that people can accelerate their journeys and be more successful. So that’s where I spend most of my time is just coaching different teams that are trying to transform their software development delivery processes.

Shimel: You know what, Gary – what we should have mentioned though – for maybe folks listening out there who may want to engage your team to help them, where do they get information?

Gruver: They can just go to garygruther.com – my website. And they can also go there and download a free copy of my latest starting scaling DevOps and enterprise, the electronic copies are there. I self-published that so I can give it away. Authors don’t really make money on books. So it’s out there, so I can give it away.

If you read the first three chapters and then click at the end, you can get the rest of the chapters if you just give me your name, your title, where you work and where you live so that if I happen to be in the region – I keep thinking I’ll use that as a marketing tool. I haven’t sent anything out to it yet, but I’m still collecting names of the people that read the book because it feels like a good contact for me.

Shimel: And of course, you’ve updated your privacy regulations to be GDPR. Anyway, Sam let’s see – DOES – you guys are the founding partners of DOES, you’re doing these workshop, you’re helping us with sponsoring DevSecOps days. What are you doing in your spare time?

Fell: Next week we’re gonna be at Velocity San Jose if anybody is in the area, we’d love to have you stop by and see us. Yeah, we’re just looking forward to seeing everybody out in London. And it’s gonna be a super fun filled week. I mean, it’s a whole week of DevOps. I could not be happier. I’m super excited about it. really appreciate all the work that everybody is doing to try and make this community event a success. And looking forward to being in London.

Shimel: As am I. I will be at all three of these events as well and you hit it there, Sam. Both the workshop and DevSecOps, these are community events. London has a fantastic DevOps community. Looking for your support, and I think it’s gonna be a great week for DevOps. So with that being said I think we’re about out of time here. Helen – as always it’s a pleasure to hear your voice and have you on the show with us. Look forward to seeing you in person.

Gary, always a pleasure, my friend. I’m sorry, Helen – I stepped on you there.

Beal: I was just gonna say, thank you very much for having me on and really looking forward to seeing you guys as well.

Shimel: Great. Gary – as always, a pleasure.

Gruver: It’s always a pleasure to get a chance to speak with you, Alan, and look forward to helping out the DevOps community.

Shimel: Very cool – and Sam, what can I say that hasn’t already been said?

Fell: I don’t know. You could say “goodbye?”

Shimel: Okay – in that case, goodbye. This is Alan Shimel. You’ve just listened to another DevOps Chat. See you all in London for DevOps week.

— Alan Shimel

June 13, 2018
Making DevOps a Reality – Bringing in Security: Top 4 Topics

I caught up with Maria Loughlin, vice president of engineering at CA Veracode; Chris Eng, vice president of research at CA Veracode; and Alan Shimel, CEO of devopsy.kinsta.cloud, to talk more about their recent panel webinar on bringing in security to make DevOps a reality. It was enlightening to hear their perspectives on how companies can build security into its culture so that it permeates the development process. Many enterprises have realized that with the continuing popularity of DevOps comes the possibility of creating an environment that allows software vulnerabilities. In truth, more teams are integrating security testing into their development processes.

This informative session is available here on demand and worth a listen. But I’d like to share the top four topics from their discussion:

New Mindset and New Speed

As dev moves to DevOps, traditional approaches to security aren’t fast enough. Both the challenges of scale and the lack of expertise on the teams need to be addressed.

Faster, Cheaper, Better

DevOps makes integrating security easier in a few ways. First, engineers understand they need to take more operational responsibility, and that includes security; and secondly, DevOps emphasizes the investment in automation and continuous delivery of small batch sizes. As much as we automate security, it becomes less costly, transparent and readily adopted.

People Aspect in DevOps: Just as Important as the Technology

Teams do need to interact differently in a DevOps environment. The partnership must be real and show empathy, respect and flexibility. Expect the security teams to be reasonable and take a risk-based contextual approach; not everything is critical.

Most importantly, that interaction must start at the top, just as it does with Maria and Chris, with a shared goal of success and accountability.

Their Parting Advice

Make the secure way the easy way. Implementing secure building blocks not only saves time but reduces your risk. Look for opportunities to simplify and automate to optimize your investments.

Sometimes, it is best to start small. Your investments will grow over time with nurturing.

Your people are your most valuable assets. Be sure to monitor and mentor the skills gap on your team because if team members aren’t knowledgeable they can’t be held accountable. Make sure that executive sponsorship is involved and visible.

There was so much more. Luckily, you can still watch the entire webinar. It’s available here.

— BeckyArenson

June 12, 2018
There’s No Such Thing as DevSecOps
Should DevSecOps be categorized separate from DevOps?

After years of debate, few doubts remain about the viability of the public cloud for enterprise workloads. Enterprises are shifting to cloud-first and cloud-only strategies, looking to take advantage of all the good the public cloud has to offer. For applications built and deployed in the public cloud, it is all about automation. The cloud enables you to be elastic, reduce costs and deliver products faster. To achieve these goals, you need to automate your processes—building, testing and deployment.

Security Challenges of DevOps

This need for faster innovation led to the rise of DevOps, a set of practices and tools that result in tighter collaboration between development and operations. In the past, controlling the deployment processes was the responsibility of dedicated teams that wrote scripts. However, with DevOps, development and deployment merge. Software engineers must do more than write their infrastructure and business logic code; they also need to write the automation that surrounds it and take responsible for deploying it through the different stages until production.

However, even as development and operations come closer together, security has remained a function apart. While DevOps workflows are heavily automated, security checks for application and infrastructure code often are manual. DevOps and security teams are measured differently—delivery versus protection—and often are at odds with each other. The siloed approaches to security hardening that worked in the past are incompatible with the holistic, iterative software development and deployment model of DevOps.

For a developer, adding the responsibilities associated with DevOps is not complicated, but securing the environment is a different level of challenge that requires mindset shifts in multiple areas:
1. Knowledge: Software engineers are great at writing business logic. They write efficient code and develop highly available environments that can handle millions of concurrent users. However, the vast majority of developers don’t know about the latest CVEs or the proper configurations of SSL/TLS in the load balancer.
2. Pace: Successful development organizations move fast, frequently adopting new development trends and frameworks. Public cloud vendors release new features every week, and it can be difficult to follow and keep up, as engineering is usually measured by the ability to deliver and the quality of output. DevOps enables rapid release cycles, and the security must not hold them back.
3. Scale: Modern applications make the transition to work with microservices. When each development team owns its cloud environment (and sometimes multiple environments), the security teams suddenly find themselves dealing with huge distributed deployments. They can’t manually configure security when new features are released a few times a day in different environments.
4. Heterogeneity: Multi-cloud deployments are another emerging trend. New product teams are often given a free hand choosing their tools and infrastructure, and they may pick a new cloud vendor. While security teams have a voice in this decision, they do not have the last word. It may have taken the security team years to learn to deal with the existing cloud solution, and suddenly the organizational policy needs to be applied across different infrastructures.
5. Consistency: Enforcing organizational policy across different development teams is challenging. Each team has its own style, environment and development frameworks, meaning it’s never easy to ensure the security is applied uniformly.
However you choose to address all these challenges, one thing must be clear: Your DevOps cycle is not complete without handling the security.

Choosing a Security Solution

Clearly, you can’t deploy services without properly securing them—you don’t want anyone to hack into your systems and steal your (and your customers’) information. Since cloud environments are dynamic and deployments tend to span across dozens of accounts, manual steps are not an option. Automation is necessary. Whether you acquire an enterprise security solution, adopt an open source security project or write your own tools, you need to make sure that they are:
1. CI/CD ready: The solution can easily integrate into the continuous integration/continuous compliance pipeline. User-friendly APIs are required.
2. Scalable: Assessing hundreds of cloud environments requires the solution to be scalable and robust. When covering more cloud vendor capabilities, performance becomes critical and increasingly challenging.
3. Flexible: Each organization is different, and security needs can vary with each deployment. The baseline configuration of your security solution will never meet your requirements by 100 percent, so it’s important that you be able to adapt it to your needs.
4. Continuously updated: Cloud vendors add new features at a rapid pace, which also means new potential misconfigurations are generated all the time. Whatever solution you choose, it needs to match the cloud vendors’ speed and agility. Security solutions that are not being updated soon become useless.
5. Conveniently Reportable: Aggregated reporting is critical. Consuming the security findings in a convenient manner can assure that issues are properly mitigated.
6. Automatic remediation-capable: Many of the findings are easy to remediate automatically. Applying automatic remediation would enable the security team to focus on complicated tasks and reduce alert fatigue.
DevOps and DevSecOps Are (or Should Be) the Same Thing

Security is clearly an integral part of DevOps. DevSecOps is emerging to bring security and compliance management practices in line with the rest of DevOps. DevSecOps serves to call out the temporary chasm that exists between security and DevOps.

As security checks and controls get automated and integrated, DevOps and DevSecOps are converging to the same thing. Just like adjusting the mirrors and putting on the seat belt are part of standard procedure before pulling your car out of the driveway, assessing your security posture before releasing a new version of your product must become habit. To remain relevant, your security team must integrate into the CI/CD and make sure the newly created environments meet organizational policies.

— Offir Zigelman
June 7, 2018
Aqua Security Survey Finds Sharp Rise in DevSecOps

A new survey of 80 cybersecurity professionals that attended the recent RSA Conference 2018 event finds the number of organizations that have a formal or informal DevSecOps team in place has increased by several orders of magnitude year over year.

The survey, conducted by Aqua Security, finds 62 percent of respondents have a formal or informal DevSecOps team. That’s up from last year, during which a similar survey found only 13 percent of respondents had a DevSecOps team in place.

It’s still early days when it comes to implementing DevSecOps processes. But Andy Feit, vice president of go-to-market for Aqua Security, said the survey also makes it clear that these formal and informal DevSecOps teams have access to budget dollars. More than three-quarters of respondents (76 percent) said their application security budget has increased over the past five years. One-quarter (25 percent) reported the application security budget went up between 10 percent and 30 percent, and another 14 percent said budget dollars being allocated to application security increased by more than 40 percent.

Well over half of respondents (57 percent) said they have the human and financial resources in place to implement DevSecOps. A total of 70 percent of respondents said they believe their culture can embrace the change needed to fuse security and DevOps. Nearly half the respondents (47 percent) reported they are fairly or very mature in their implementation of DevSecOps, while another 39 percent ranked themselves as maturing.

The three most important elements of DevSecOps as ranked by respondents ranked applying security across the app life cycle (61 percent), automating application security controls (52 percent) and involving DevOps in security processes (43 percent).

The shift to DevSecOps is occurring in tandem with increased reliance on microservices that are based on containers. As that shift occurs, Feit said IT organizations are rethinking their approach to application security. In delivering applications as a series of microservices, it becomes critical to apply a more granular approach to securing those applications that developers can apply as they build applications. Cybersecurity professionals will then be able to focus more of their efforts on crafting the security polices that developers implement, he said.

It may take a while longer before cybersecurity professionals gain enough confidence in containers to deploy them on physical servers with relying on a hypervisor to provide isolation. But it’s also now only a matter of time before developers insist on deploying containers applications on bare-metal servers to attain the maximum amount of performance possible by eliminating all the overhead added by a virtual machine. As that shift occurs, IT organizations will need new tools to secure and manage containers running on bare-metal servers.

As the same time, it’s clear that securing all those containers will require new processes such as DevSecOps because instead of patching applications to remediate them, developers will more easily replace specific containers to add new functions. Less clear is whether the adoption of DevSecOps will be driven from the top down or more as a grassroots initiative driven by the mutual self-interest of developers and IT security professionals. Regardless of the approach, cybersecurity as it is known today will not only be much different, but also arguably better.

— Mike Vizard

June 6, 2018
Using Blockchain to Advance IoT

Imagine two disruptive technologies come together to democratize transparency and connectivity in the tech world. That’s exactly what’s happening with blockchain technology, once synonymous with powering cryptocurrencies including Bitcoin, has the potential to be a disruptor in a number of verticals and the internet of things (IoT), with blockchain addressing key IoT security concerns.

About Blockchain

The blockchain is the transaction recording distributed computer ledger. Its major use traditionally has been in securing the transaction of cryptocurrencies over the internet. Different users have their own wallet, which serves as a node in the blockchain network connected to the internet. Transaction messages can be sent in an encrypted form, which acts as a digital signature and does not allow tracing of the user’s wallet or tampering with any data stored there. Each wallet is controlled by a public key and a private key. To initiate a transaction, the user broadcasts an encrypted message in the network using the private key and the message can be decrypted by other network members using the public key. To materialize a transaction between the users, it needs to be approved by the majority of the nodes to help detect any fraud or data-breaching attempt before finalizing the transaction. So, it is the public that is controlling transactions, unlike banks or other financial institutions.

About IoT

IoT is a concept of embedding everyday-use items with sensors and other electronic components for enabling connection and data exchange between these objects. It is growing at a fast pace, and internet-connected devices increasingly are being used in different industries. IoT has made life easier, with smart devices that can be controlled using mobile apps, and can even be programmed using artificial intelligence.

To function most effectively, IoT devices generally take user information, which means there are security risks. As a result, IoT development is lagging and IoT vulnerability to cyberattacks due to the lack of a robust centralized security model is a real concern.

Blockchain and IoT Complement Each Other

It is evident from history that whenever two complementary technologies merge, new, dynamic products are formed. The greatest advantage provided by blockchain technology is security of data, which happens to be the most difficult challenge faced by IoT. Immutability, decentralization and transparent data-sharing are the most significant advantages of blockchain that are lacking in IoT, and the IoT community wants to integrate these features for data security. User privacy can be maintained in cases where desired by grouping and classifying anonymous individuals or groups under an über Do Not Track (uDNT) system. The smart IoT devices can use the data and information stored on blockchain efficiently for performing various tasks. Blockchain also can help in IoT scaling as it struggles for growth.

Blockchain also benefits from being paired with IoT, as it is showing its worth in a new domain of application apart from cryptocurrencies that most would consider to be much more useful on a daily basis. Thus, the two disruptive technologies complement each other and can reap dynamic solutions for different industries when used in conjunction.

Security of Data is Enhanced

IoT needs a robust centralized security model to grow in acceptance and use—something blockchain technology and the cryptographic processes driving it can offer. More and more offline objects are being converted into online assets with IoT, thereby increasing the risk of cyberthreats. Businesses, therefore, need to plan strategically for the protection of not just the smartphone and desktop computer, but almost everything connected to the internet. The objects in IoT ecosystem can act analogous to the nodes in blockchain technology, thus making connected home, connected cars and other connected devices more reliable and secure with blockchain-based IoT.

Data Analysis and Intelligent Use of Data

By leveraging other technologies such as artificial intelligence (AI), businesses using IoT along with blockchain can uncover useful insights through data analysis and understand the consumer requirements and market trends in a better way.

User Interconnectivity is Enhanced

With the transparency provided by blockchain, the users can make the best use of the interconnectivity provided by IoT to the networks of smart devices. IoT users can connect with each other in more beneficial ways and discuss their issues and queries more openly to gain different insights.

Privacy and Integrity of Data is Increased

With the increased amount of data, the privacy of data is gaining more importance as powerful IoT companies are tracking almost everything about the users. Lack of proper encryption and data leakage not only put individuals at risk, but also makes industrywide business models vulnerable. Using blockchain with IoT not only makes data immutable, tamper-proof, verifiable and transparent, but the data also is encrypted correctly to preserve user privacy.

Transactions are Fast and Small

Certain companies plan to incentivize users with small rewards for sending data, such as by paying a percentage of their electricity bill, providing points or paying the user, thereby creating a new route for earning a passive income. However, with banking fees often outweighing the transaction itself, this idea currently is not feasible. Blockchain can help to solve this problem.

Transactions can be Automated

Using blockchain, the services and transactions made by IoT devices can be automated without human interference. For instance, an autonomous car would be able to pay for a refill, parking fees or mechanic fees by enabling smart contracts that follow the “IFTTT (IF-this-THEN-that)” command.

Infrastructure, Operational Costs are Reduced

Using blockchain, the infrastructure for projects can be outsourced and the cloud side of IoT can be handled by the network. The need of any middleman and the legal and contractual costs, along with the maintenance, update, and supervision costs are cut down. This leaves ample time and money with the companies to focus on the hardware, application, and innovation side of things.

How will Blockchain Combine with IoT?

In the near future, a conventional, centralized model will not be able to manage the data produced by IoT, so, the decentralized approach of blockchain technology will be necessary for data management to avoid data tampering, single-point failures and third-party interference. The entire data is shared across the network like a shared ledger updated in real time.

Comprehensive Blockchain-IoT Approach

To face growing competition in the market, businesses that adopt the blockchain-IoT approach earlier are bound to be more successful. A suitable blockchain-IoT app development company is one that has the following characteristics:

Domain-specific knowledge: Data intelligence needs to be applied along with the knowledge of specific domain to derive the warranted performance or result from investments.

Development intricacy: With the growing business needs and customer expectations, businesses expect a high-performance computing infrastructure. Thus, the company should be able to deal with the business operation and data processing complexities.

Data management on a large scale: For storing and processing large amounts of data, AI and machine learning need to be used. The company must have a hands-on experience in data handling and processing using these techniques.

Final Thoughts

Blockchain and IoT together can be a game-changing technology for the mobile world. Many companies will benefit from the added security and automation offered by blockchain. In the very near future, we are going to see how blockchain solutions will rule the commercial IoT world and futuristic companies will undertake the process of developing and implementing it themselves.

— Juned Ghanchi

June 4, 2018
Don’t Forget to Automate Cloud Security

Cloud has been around long enough, and we’ve had enough breaches stemming from unsecured cloud (mostly data objects, but other items, too) that we should know better. I cringe whenever I see a security headline along the lines of “… Unsecured S3 Bucket.” Would you publicly expose a server in your data center and not lock it down? No.

So, what is the problem? Frankly, “cloud” now consists of so many separate-but-integrated offerings that it can be daunting, even improbable, for security staff to lock it down. Add in dozens or even hundreds of instances/storage locations/routers, and you have a separate data center with different requirements—at least, that’s what it essentially is for your security team. Then add agile and DevOps, spinning up new infrastructure and changing the parts at a rapid pace, and you have a fast-moving, complex data center environment. Yet, if you are a typical organization, your security staffing hasn’t significantly changed, nor do you have requirements for securing the physical infrastructure. In short, same group of individuals, a ton more work to do.

Before it was purchased by VMware, I had the pleasure of working with CloudCoreo, and truly liked what I saw. The problem in highly automated environments, be they DevOps or just automated, is that a lot of parts are moving as the system is maintained/updated. Some of those parts are changing security settings in a complex (data center-size complex, in many cases) environment. For security teams to keep up and be part of DevOps—or just keep up with automation—quite often corners must be cut.

That’s bad for all of us—security staff, the company and customers. If anything, when the cloud environment grows complex, security needs to be more cautious, not less. And yet, the number of data leaks/exploits that involve “misconfigured” security settings in the cloud says we have a problem.

So what to do? One option is to check out security control and auditing software from the likes of RightScale, Dome9 or Evident.io. (DISCLAIMER: I have not used any of these tools. They were chosen because each shares attributes with CloudCoreo, which I have used.)

The ability to scan and apply policy to a broad array of cloud artifacts—from users to back-end storage—is essential in allowing security to keep up with DevOps. There is just too much change in a fully automated cloud-based environment to expect security to keep up without the same level of tools as developers and ops get. “Shift left” doesn’t stop misconfigurations, but scanning can detect them, and some tools can even auto-fix those misconfigurations.

In the end, protecting systems and data is what the security team does. Bringing them along on the DevOps grand tour and offering them the same type of automation opportunities as the rest of IT is benefiting from is mandatory. It is not “would be nice to have” to give security the chance to keep up; it should be a requirement.

And you might still have rogue S3 buckets that security doesn’t know about that might be misconfigured, but any that are paid for by the corporation will be available to security and those automated tools and, thus, will be locked down.

And if security isn’t enough of a reason for you to want to implement one of these tools, “Come for the compliance, stay for the security.” Most solutions offer auditing that helps with compliance.

— Don Macvittie

June 1, 2018
Securing Third-Party and Open Source Code Components: A Primer
The increasing popularity of open source code continues to be a boon for developers across the industry, allowing them to increase efficiency and streamline delivery. But there are security risks to be considered when leveraging open source and commercial code components, as each carries with it a significant risk of becoming the enemy within, creating a vulnerability in the program it helps build.

Sacrificing Security for Ease of Use

While the many benefits of open source have been well-touted, the sheer prevalence of code components (open source and commercial) across industries is underestimated. CA Veracode recently found that 83 percent of developers use code components to build web applications, with the average number of components per application at a whopping 73.

Considering the fact that the vast majority of developers build applications with code components, the number of those familiar with the risks of doing so is startlingly low. A mere 52 percent of companies reported they provide security fixes to components when new security vulnerabilities are discovered. Despite an average of 71 vulnerabilities per application introduced through the use of third-party components, only 23 percent reported testing for vulnerabilities in components at every release.

Furthermore, only 43 percent of developers reported being aware of the industry-accepted OWASP recommendations for preventing the use of components with known vulnerabilities.

Where Does Responsibility Lie?

One clear issue in this software development practice is that responsibility for securing code seems to fall on everyone—and, sometimes, no one. Forty-four percent of respondents claimed that developers are responsible for the continued security of code components, while 31 percent reported that they expect security to handle this task.

This lack of preparedness and miscommunication leaves the door wide open for bad actors to swoop in and take advantage of vulnerabilities that could so easily be fixed.

How, then, can teams ensure the security of applications built with code components? The solution lies in three key steps:
- Start with education: Software development teams must have the tools and training necessary to ensure the code they write is secure. Educating developers on the risks associated with open source and commercial code components is a start, but prioritizing security training and ongoing education is the key to long-term success. Tapping the security team to lead trainings for their developer colleagues is a good way to embrace peer knowledge-sharing and break down silos between the two teams.
- Introduce clear processes: To alleviate miscommunication and confusion, organizations must implement clear processes for secure software development. Knowing what an application is built of is the first step, as teams can’t secure what they don’t understand. This may seem obvious, but CA Veracode found that only half (53 percent) of organizations keep an inventory of components. Code components should be thoroughly vetted before being worked into an application and then should be added to a working inventory. Managers should be sure each part of the maintenance process has a clear owner on the team so responsibility is always clear. Consistent testing and patching are also best practices when it comes to security.
- Drive innovation with DevSecOps: All of this comes back to integrating security into the entire software development life cycle (SDLC) and implementing DevSecOps, because a team that operates in silos will never be able to push out secure code. The development, operations and security teams each provide their own unique and critical contribution to the software development process, and combining forces will result in the best possible product.
While taking the time to secure applications from the perils of code components may slow down development in the short term, safeguarding your organization and its software assets is invaluable in the long term.

— Pete Chestna
May 24, 2018
Continuous Discussions Video Podcast: DevSecOps, Best Practices and More

In a recent episode of the Continuous Discussions (#c9d9) podcast, a group of industry experts discussed why DevSecOps is officially more than just a buzzword, tips on how to get everyone in the organization to own security and some of their own challenges and experiences baking security into the software delivery pipeline.

The panel included: Alan Shimel, editor in chief at devopsy.kinsta.cloud; Chenxi Wang, managing general partner at Rain Capital; Derek E. Weeks, VP and DevOps Advocate at Sonatype; Paula Thrasher, Chief Architect, National Security Division at GDIT; Geetika Tandon, director of technology at Federal Civilian CTO Group; and Electric Cloud’s Sam Fell and Anders Wallgren.

Continue reading for some of their top takeaways!

Why DevSecOps?

DevSecOps is really more about a cultural shift, said Shimel: “DevOps is DevOps. It’s not just about Dev and Ops, though. DevOps is about the whole organization adapting a common cultural way of interacting including security, and bringing security into that culture, into that software ordination assembly line.”

Integrating security into development practices takes a lot of collaboration and communication, per Wang: “It’s easy to say security should be part of the process. But in practice, it’s difficult to do. When you have a security testing process that takes days to complete from the input to the output, and then you have developer teams releasing 500 releases a day, those are two very different cultures. It’s usually an iteration process but it takes a lot of team communication, a lot of sitting down, figuring things out for security to be part of it, and so it’s a not an easy process.”

Why DevSecOps and not just DevOps? Well, security people weren’t necessarily invited to the party, explained Thrasher: “It’s a cultural challenge that security hasn’t necessarily been an integrative part of a lot of the DevOps transformations. I think ‘DevSecOps’ exists because either we’ve left security out or they’ve stayed outside this transformation that’s happening.”

There really shouldn’t be a trade-off between security and quality, according to Wallgren: “I long for the day when we don’t distinguish between security and quality because, yes, there are different disciplines to them in some extent, but as far as the end user is concerned a bug is a bug.”

Weeks wanted to let nonbelievers know that DevSecOps is real and more than just a buzzword: “DevOps and security can integrate with each other and integrate successfully at scale. There are organizations of a couple of hundred or even a couple of thousand people that have a DevSecOps practice in place that are continuously improving it, adding an automated security, so it’s definitely gone beyond buzzword status.”

Including security in the release process should be a no-brainer, according to Tandon: “I think of it as common sense. I don’t even understand how security has been left out. I don’t understand how we have these huge pipelines, we’re releasing a hundred code releases a day and then, boom, we’re stopped. We’re stopped for scanning.”

Common Barriers to DevSecOps and Patterns for DevSecOps Success

Progress takes time, but Shimel remains hopeful of the future: “We’re not going to boil the ocean or change the world in a day, but we will change the world and we will change the way software is delivered so that software and security is synonymous with quality.”

Wang explained how one company is utilizing automation to successfully bake security into their process: “A company that I have worked with is in the container world and they have what they call a Brown’s registry. So they have code that is assembled by the development team and then goes into a Brown’s registry. No other code can get in to the Brown’s registry unless it’s from their own team. Then from that Brown’s registry the security team automatically goes in and scans it and then only those that pass the scan gets put into what they called a Gold registry. And from there then they could deploy it to the server.”

Everyone in the organization should practice and be prepared to respond to security incidents, advised Thrasher: “The people that need to practice responding to vulnerabilities the most actually aren’t the security people. They’re used to responding to security issues. It’s the ops and the developers who aren’t used to responding to security incidents and they aren’t equipped, they aren’t trained on how to respond. So when your vulnerability happens it’s a bad new story.”

Many security issues have been around for a notorious amount of time, which is where the software delivery industry can improve, said Wallgren: “Where are most of the exploits coming from? The vast majority of them as I understand it are coming from well-known longstanding security issues that have been out there for a long time or, at least long by technology standards. And so a lot of it is just simple stuff that we need to be better at.”

Security as code is the next step in truly integrating security with DevOps, explained Weeks: “I was just talking to someone in Europe at a big telecom company, and they were saying, ‘I’m on the security team, we’re working with development, and we’re getting closer. We have all these rules and things that developers need to follow and we’ve been working with getting them to follow them more.’ And I said, ‘That’s really cool. Any of those rules or policies instrumented as code?’ And he responded cross-eyed like, ‘What? Code?’”

Tandon shared an eye-opening experience with a customer: “I’ve seen a situation where we were about to go to production—it was DevOps with security toward the end—and we got 4,000 hits and we had to go to production, most of them were ignored. So are we really securing our system or are we making our own system even more insecure by doing that?”

Watch the full episode:

Want to dive deeper into DevSecOps? Industry expert John Willis, co-author of “The DevOps Handbook” and “Beyond The Phoenix Project” and VP of DevOps and Digital Practices at SJ Technologies, is scheduled to lead a full day hands-on workshop immediately following DevOps Enterprise Summit in London and Las Vegas. Register soon—space is limited!

Register for the London workshop

Register for the Las Vegas workshop

— Anders Wallgren

May 16, 2018
Open Source: Is Your DevOps Org Vulnerable to an Equifax-Style Hack?

More than half of the Fortune 100 could be at risk of falling prey to the same kind of hack that caused devastation at Equifax last year, and it all comes down to poor open source component governance.

A new report out from Fortune reports that in the year after Apache Software Foundation issued an update to its Apache Struts framework to fix a well-known and critical deserialization vulnerability, more than 10,000 organizations downloaded the vulnerable version instead. Among those were 57 percent of the Fortune 100, according to numbers provided to Fortune by Sonatype.

The vulnerability is best known to have triggered the catastrophic breach at Equifax in 2017 that exposed the records of 148 million people. It’s a doozy of a flaw—a command injection vulnerability that allows for unauthenticated remote code execution—the kind of opening that gives attackers to gain a powerful foothold in affected systems.

“Seven months should be enough time for organizations to install the necessary patches and it’s unfortunate that so many still choose to download the older vulnerable versions,” said Nick Bilogorskiy. “There is really no excuse for this.”

This news should be sobering to DevOps organizations. Increasingly, they’re turning to an assembly-focused mode of software delivery that relies heavily on open source components rather than developers reinventing the wheel with new code. It offers a wake-up call for DevOps organizations to get serious about tracking and securing the third-party code they use.

In a recent DevSecOps survey conducted by 451 Research on behalf of Synopsys, 40 percent of organizations don’t perform any kind of software composition analysis on their software. That’s problematic, because it means that organizations often don’t know when vulnerable open source components such as Apache Struts are woven into their code base.

More disconcertingly, even fewer organizations have systems in place that can actually control when, where and what open source components are used within their software development. According to a different DevSecOps survey conducted by Sonatype, 62 percent of organizations don’t have any meaningful controls over which components are in their applications.

It’s a disconcerting statistic, considering the sheer volume of open source component use in development today—whether in DevOps shops or not. In a talk titled, “We are ALL Equifax” at the DevOps Connect event held at RSA conference last month, Derek Weeks highlighted the fact that open source component download requests have increased 87 times in the last 10 years.

“The growth rate and consumption volume is massive. And it’s coming into your organization,” Weeks told the audience. “And as a result of this behavior the applications your developers are building are now 80 percent to 90 percent open source components—built from code you did not write from scratch.”

Sonatype’s survey shows that almost 1 in 3 organizations this year suspect or have verified that they’ve suffered from a breach related to open source components in the last 12 years.

— Ericka Chickowski

May 11, 2018