Key Findings from the 2019 State of DevOps Report
•Download as PPTX, PDF•
1 like•515 views
This document discusses findings from the 2019 State of DevOps report regarding security integration. It finds that security is not always a top priority for development teams. It also analyzes different levels of security integration in software delivery cycles and the impact of security practices on organizations' confidence in their security posture. Practices that involve collaboration between security and development teams are found to most improve security. However, the document also notes there can be friction between teams and that fully integrating security is messy.
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Key Findings from the 2019 State of DevOps Report
Similar to Key Findings from the 2019 State of DevOps Report (20)
More from Puppet
More from Puppet (20)
Recently uploaded
Recently uploaded (20)
Key Findings from the 2019 State of DevOps Report
- 1. 2019 State of DevOps Report Findings
- 2. 8 years of DevOps research
- 4. Good security doesn’t pay the bills.
- 5. 5 Cost of fixing defects by delivery phase Source: IBM System Science Institute
- 6. Security is not a priority • 88% growth in application vulnerabilities over two years • 78% of vulnerabilities are found in indirect dependencies • 37% of open source developers don’t implement any sort of security testing during CI and 54% of developers don't do any docker image security testing • Median of 2 years from when a vulnerability was added to an open source package until it was fixed6 https://snyk.io/opensourcesecurity-2019/
- 7. Levels of security integration During which of the following phases of your software delivery cycle is security involved? Software delivery phases • Requirements • Design • Building • Testing • Deployment 7 Levels of security integration • Level 1- No integration in any phases • Level 2 - Minimal integration (1 of 5 phases) • Level 3 - Selective integration (2 of 5 phases) • Level 4 - Significant integration (3 or 4 of 5 phases) • Level 5 - Full integration (all phases) % of respondents at each level of security integration
- 8. Doing DevOps well enables you to do security well.
- 9. Cross-team collaboration builds confidence in security posture.
- 10. Security integration and confidence in security posture 10 Respondents feel their organization’s security processes and policies significantly improve their security posture.
- 11. Top 5 practices that improve confidence in security posture Practices that span multiple teams and promote collaboration are most impactful • Security and development teams collaborate on threat models. • Security tools are integrated in the development integration pipeline. • Security requirements are prioritized as part of the product backlog. • Infrastructure-related security policies are reviewed before deployment. • Security experts evaluate automated tests. 11
- 12. Security practices and their effects on security posture 12 Frequent use / lower importance • Domain specific tests • Penetration testing • Infrastructure provisioned / configured automatically using security-approved procedures • Dependency checkers • Static code analysis • Security requirements tested as design constraint Infrequent use / lower importance • Developers can provision security hardened infrastructure stack on demand • Security review occurs after new application code released to production • Security personnel review / approve minor code changes before deployment Frequent use / higher importance • Infrastructure-related security policies tested/reviewed before deployment • Security requirements prioritized as part of product backlog Infrequent use / higher importance • Security and dev teams collaborate on threat models • Security tools integrated into the dev ecosystem so developers can implement security features during development phase • Security experts evaluate automated tests • Security personnel review/approve major code changes before deployment
- 13. Integrating security leads to positive outcomes.
- 14. Ability to deploy vs. actually deploying 14
- 15. Time to remediate critical vulnerabilities 15
- 16. Ability to prioritize feature delivery vs. security improvements 16
- 18. Friction between teams 18 Respondents feel security team encounters a lot of friction when collaborating with delivery teams.
- 19. Security integration and audit issues 19 Security issues revealed by audits always or often require immediate attention.
- 20. Thank you.
- 21. Security is a shared responsibility 21 Security is a shared responsibility across delivery and security teams.
- 22. 22 Responses by global region
- 23. 23 Industries
- 25. 25 Department
- 26. 26 Teams
Editor's Notes
- Hi, I’m Alanna Brown, Sr. Director of community and developer relations at Puppet. I started something called the State of DevOps Report back in 2012 before anyone really knew what DevOps was or what it would become. Like many of you, I thought DevOps would be dead in a year.
- And here we are today, still talking about DevOps. In fact, I’ve spent the past eight years, surveying over 33,000 technical professionals from around the world, and working with the larger DevOps community and Puppet customers to understand how organizations adopt and scale DevOps practices and the outcomes they’re seeing.
- In just a few hours, we’re releasing our 2019 State of DevOps Report. This year’s report focuses on one of the most challenging aspects of DevOps: integrating security practices into the software delivery lifecycle. Security is often seen as a necessary evil, but it doesn’t have to be that way. This year’s research shows us that integrating security early and often delivers results even if the path to get there isn’t straightforward.
- Intro slide - Welcome to the topic; introduce context; what we decided to focus on; introduce ourselves, what we found interstin
- Testing in production / driving down costs Tech advancements; microsfervices, containers; cheaper to fix in microservice vs. monolith
- Why? What do you see about landscaipe? Myike - doesn’t matter; Org issues / feature development
- How do we solve this problem? We’ve seen successful patterns emerge from DevOps that have enabled organizations to build quality and deployability into the software delivery life cycle. There are also organizations out there having success baking security in from the start. We wanted to know if integrating security throughout the software delivery life cycle actually delivers positive outcomes. I’ll be referring to “levels of security integration” throughout this presentation. The way we defined those levels was by asking people to select all the phases where security is involved. We then broke those answers out into five levels: Level 1 - No integration of security in any of the phases Level 2 - Minimal integration (one of five phases) Level 3 - Selective integration (two of five phases) Level 4 - Significant integration (three or four of five phases) Level 5 - Full integration (all phases) 60% of firms include security in two or fewer phases of their software delivery cycle. So most organizations aren’t at a very high level of integration. Combine 2 slides Nigel ask Andi about bell curves -
- Roundtable Yeah, I know, some of you are like “Obvious. Move on.” But most research exists just to prove what we all already know. If you’ve already started on your DevOps journey, good news, you are building the capabilities that will enable you to deliver software more securely. Use of version control and continuous integration, automated testing and automated deployment provide an amazing foundation to build other capabilities. It makes it so that making a security-related change is the same as making any other change. Last year, we discovered that at the highest levels of DevOps evolution, security policies and incident response are highly automated and security teams were involved early in technology design and development. We wanted to know if this works the other way around. As you can see from this trendline, the more integrated security becomes the more likely a firm will also be at a high stage of DevOps evolution. 22 percent of firms at the highest level of security integration are also at an advanced stage of DevOps evolution.
- We found that as security become more integrated, confidence in security posture improves. Does confidence equote to actual security
- 81% of respondents at firms with high integration felt that their security policies and practices significantly improve their security posture. Compare this with respondents at firms with no security integration — just 38 percent had that level of confidence. Now that doesn’t necessarily mean that they actually are more secure. What’s more important here is the shift in mindset. When there’s no integration, there’s usually a lack of understanding of the work involved in security and a lot of cynicism. But when teams are fully integrated, there’s a shared understanding and people feel like the things they’re being asked to do really do matter, which makes them more likely to actually do them. If you were to guess what the most impactful practices are for improving confidence in security posture, what would they be?
- What does it mean to actually collaborate across teams How do you make this happen? How do you get people to collaborate on threat model: how do you get vp engaged? Inviting security expert on scrup, having htem sign off on release? Practical and actionalable Anectdotes; anti patters; if you don’t do this what blows up; What works what doesn’t work; We threw in a bunch of practices and I thought for sure that the more tactical practices, like testing would be at the top of the list. Me and my fellow authors were delighted to find that the practices that require strong collaboration and sharing amongst teams were actually the top confidence-builders. The top five practices that improve security posture are: Security and development teams collaborate on threat models. Security tools are integrated in the development integration pipeline so engineers can be confident they’re not inadvertently introducing known security problems into their codebases. Security requirements — both functional and non-functional — are prioritized as part of the product backlog. Infrastructure-related security policies are reviewed before deployment. Security experts evaluate automated tests, and are called upon to review changes in high-risk areas of the code (such as authentication systems, cryptography, etc.).
- Make a list of things - We mapped all of the practices on a quadrant. The x axis represents the importance of the practice as it relates to improving confidence in security posture and the y axis represents the frequency of these practices. The practices on the left are tablestakes. Those are the things you should be doing anyway. The practices on the right are where you should be focusing your effort. Again, these practices require deep collaboration and happen early in the development cycle. It's not just about shifting security checks left, it's about fundamentally changing the way everyone works earlier in the pipeline. Our recommendation is to start focusing on the practices in the bottom right quadrant because those are the ones that are infrequently used but are incredibly important to improving confidence in security posture.
- Ok, so this is all great feel good stuff, but you might be wondering if any of this actually has an impact on business outcomes?
- Just because you can doesn’t mean you should, but beting able to makes you agile in good ways; Question: deployment frequency bullshit vnity metric discuss? Goes up then goes doen then goes up again; pain is real; gets worse betfore it gets better; Best thing you can do is not try and then not fail This year, we asked two questions about deployment frequency. How often can you deploy versus how often do you deploy. We know of enough organizations now that can deploy more frequently than the business or their customers require. This is a far cry from a few years ago when everyone was obsessed with improving their deployment frequency. I actually think it’s a huge measure of success for a DevOps initiative if you can now deploy so frequently that your marketing team asks you to slow down because they can’t keep up. If you focus on this teal green bar here to the left, this is the percentage of respondents at each level of integration that are able to deploy on demand. Firms at the highest level of security integration are able to deploy to production on demand at a significantly higher rate than firms at all other levels of integration — 61 percent of highly integrated organizations are able to deploy on demand compared to 49 percent of organizations with no integration.
- Doing remedation is good; doing it well is hard; Doing more security finding more problems Unpack level 1 - not integration - same team that does everything; just ops work; small org so can move quickly; security team just process security people and you handle all the other stuff; 45 hae rigor in rpodess A couple of interesting things to point out here. First only 7% of total respondents are able to remediate a critical vulnerability in less than one hour. The majority of respondents are able to remediate in less than a week. The main takeaway for me is that it’s really hard to actually reduce the time it takes to remediate vulnerabilities because there are too many factors involved, too many stakeholders, handoffs and approvals. The differences you see here between each of the levels are statistically significant, but they’re not as dramatic as we’d like. But still, any reduction is a good thing because that does reduce your company's risk and exposure.
- Low severeity different from other results: two of the most clustered; lowest severity and crtical ones why is that? Critcal security is blank check to do whatever it tkes to get it done; med and high interestin and prove processes work; drop everything and fix everything is simple; Gap between level 1 and level 5; ; hard to do Now imagine with me for a minute that you were asked to choose between making a security improvement or delivering a critical new feature that your customers have been asking for and will help you make your quarterly number. Which one would you choose? We asked a series of questions about like this and found that firms with deeper security integration were more likely to prioritize security improvements over feature delivery.
- So far, I’ve painted a rosy picture, but the reality is that integrating security is messy work, especially in the early stages. When you’re just starting you don’t know what you don’t know. As you dig deeper though, it can feel a bit like opening Pandora’s box. All of the duct tape and glue that’s been holding everything together is suddenly laid bare before you. We’ve seen this in past reports, too. It’s called the j-curve, which means things start out well because you’re seeing quick wins and then they take a turn for the worse before they get better again.
- Crossing org boundaries We asked if security teams encounter friction when collaborating with delivery teams. Friction is higher in the middle and it never really goes away, even when teams are fully integrated. When we compared those in security roles vs. non-security roles, we found that friction was even higher for security teams in the middle stages. Understanding that DevOps is fundamentally about cultural change, it’s imperative to remember that different teams will experience this change differently.
- Mike rant Increasing security integration also doesn’t reduce the number of issues that require immediate correction that arise from audits. The path is hardest at levels 2 and 3. We looked at number of audits firms were performing at each level and it turns out that at higher levels of integration, firms are actually doing more audits per year, since often times audits are elective and you can select the degree of difficulty for some audits.
- Add devopssurvey.@puppet.com
- So far, I’ve painted a rosy picture, but the reality is that integrating security is messy work, especially in the early stages. When you’re just starting you don’t know what you don’t know. As you dig deeper though, it can feel a bit like opening Pandora’s box. All of the duct tape and glue that’s been holding everything together is suddenly laid bare before you. We’ve seen this in past reports, too. It’s called the j-curve, which means things start out well because you’re seeing quick wins and then they take a turn for the worse before they get better again.