DevSecOps<\/a> represents the reality that DevOps<\/a> must grow to encompass security. <\/strong>Eventually, performant code will mean secure code by default – but we’re not there yet. How do we get there?<\/p>\n\n\n\n Let\u2019s start with where we are now. Earlier this year, Checkmarx ran a survey asking organizations about their current AppSec programs. One of our questions specifically asked: \u201cWhere are you on your DevSecOps journey?\u201d You can see the answers below:<\/p>\n\n\n\n And let\u2019s be clear \u2013 integration and automation are the goals of DevSecOps. DevSecOps is about taking the needs and outcomes of application security and integrating them with the processes and culture of DevOps. In 10 years, there should be no difference between \u201cDevOps\u201d and \u201cDevSecOps.\u201d DevSecOps is just what DevOps needs to be when it grows up.<\/p>\n\n\n\n OK \u2013 how do we get there? If I were to create a rough sketch of DevSecOps maturity, it would look like this:<\/p>\n\n\n\n The next level focuses on the developer experience. Here, AppSec teams and developers alike realize that \u201cShift Left\u201d isn\u2019t really working. Not because anyone is bad, uncaring, or unintelligent, but because it is only intended to be the first step. In that stage, AppSec got tools to find and triage vulnerabilities. Now developers need tools to manage those vulnerabilities themselves without breaking their workflow. The \u201cdeveloper experience\u201d stage of maturity focuses on IDE-integrations, remediation guidance, and other ways to keep developers focused without greatly disrupting their flow.<\/p>\n\n\n\n But like \u201cShift Left\u201d, focusing on the developer experience eventually hits diminishing returns. Organizations will get stuck, and then they will need to begin to move towards the third step of maturity. This is where you take the foundational understandings of the first two steps, and work to define a DevSecOps culture.<\/p>\n\n\n\n Culture is hard to change, but luckily, DevOps people have done it before. If you go back to the early days of Agile and Scrum, teams would hold daily standups, and then go back to working exactly the way they had before. But, as modern DevOps organizations can confirm, it\u2019s worth the effort. For DevSecOps, it\u2019s also worth the effort: By making this transition, teams can finally end the guesswork of which vulnerabilities are critical and have to be dealt with right away, and which are just minor fixes that can wait.<\/p>\n\n\n\n With Checkmarx\u2019 automatic prioritization, they already know. Developers can use their time more efficiently and substantially reduce alert-fatigue (since alert noise is cut by up to 90%). And with features such as AI Coding Assistant, guided- and auto-remediation, best-fix location, and Codebashing, Checkmarx also gives developers the tools and information needed to fix vulnerabilities fast.<\/p>\n\n\n\n Here is an example of a Checkmarx customer journey, and you can see them go through the stages and the results:<\/p>\n\n\n\n If you\u2019re curious about the types of things this customer did to get from the left to right side of the graph above, here we\u2019ve got some examples ready based on where you are from a maturity standpoint:<\/p>\n\n\n\n Shift Left:<\/strong> If you just need to get something in place to start getting vulnerabilities over to developers, the easiest way is to integrate your AppSec tools with your feedback tool (be cautious here, you don\u2019t want to suddenly shunt 10,000 JIRA tickets over to the devs, so set some policies around it). Click here<\/a> to see a video showing how easy that integration is to do with Checkmarx.<\/p>\n\n\n\n Developer Experience:<\/strong> The easiest way to start improving your developer experience is by integrating with their IDE of choice. This is also simple to do with Checkmarx, and here is a video showing how: Watch Now!<\/a><\/p>\n\n\n![\"Devops](\"https:\/\/checkmarx.com\/wp-content\/uploads\/2024\/10\/Images-for-the-blog-01-1024x396.webp\")
<\/figure>\n\n\n\n
On the surface, this doesn\u2019t look too bad\u2026 until you consider the details. Based on our scaling, \u201cmedium\u201d only represents the \u201cdefinition and strategy\u201d phase. The actual process of integration and automation is where companies actually start \u201cdoing\u201d DevSecOps, and only 1 in 5 companies surveyed have reached that stage in some form.<\/p>\n\n\n\nDevSecOps: The Path to Maturity<\/h2>\n\n\n\n
![\"DevSecOps](\"https:\/\/checkmarx.com\/wp-content\/uploads\/2024\/10\/Images-for-the-blog-02-1024x519.webp\")
<\/figure>\n\n\n\n
Let\u2019s start on the bottom. This is traditionally where AppSec<\/a> finds vulnerabilities, and essentially throws them over the wall to developers and says \u201chere, fix these.\u201d I have some bad news for you, this is actually \u201cShift Left\u201d in action. Maybe that\u2019s flippant and a bit unfair; but it is the base level of maturity that puts organizations on the road to DevSecOps.<\/p>\n\n\n\nDevSecOps: Ending the Guesswork is Worth the Effort<\/h2>\n\n\n\n
![\"Mature](\"https:\/\/checkmarx.com\/wp-content\/uploads\/2024\/10\/Images-for-the-blog-03-1024x407.webp\")
<\/figure>\n\n\n\n
This is a chart showing the number of vulnerabilities remediated by a Fortune 100 company, and it\u2019s a powerful representation of what things look like when teams integrate.<\/p>\n\n\n\n