How do organizations strengthen and mature their AppSec programs without slowing DevOps?
We previously explored a four-level maturity model framework that Checkmarx’s award-winning Professional Services team uses as a lens through which they evaluate our customers’ transitions from DevOps to DevSecOps without slowing development. Check out this maturity model here.
Let’s build upon that model with five actionable tips from the same DevSecOps experts on our Professional Services team to help you and your team successfully transition into a DevSecOps program that does not create friction for your developers.
1. Be developer-centric
Security needs to approach DevOps with policies, tools, and processes that don't work against developers. One of the most significant success factors in an AppSec program is integrating technical solutions throughout the entire SDLC. Automated scanning within developer tools supports developers who don't have time to manually kick off scans and then wait for their results. They need the process to automatically trigger scans that don't interrupt the way they work.
For example, a customer with SAST and SCA scans integrated into a pipeline build had difficulty ensuring the developers would review and remediate scan results. Due to the scans executing in the build pipeline, the developers needed to navigate to the result review portals after each build. This step would frequently be skipped.
As a solution, Checkmarx SAST and SCA scans were integrated into the developer’s Git source control system to streamline the delivery of results to developers. Developers opening a pull request to deliver code-complete features would invoke SAST and SCA scans. A summary of the vulnerabilities would then post to the pull request comments. The result summary had links directly to code and vulnerability details, allowing the developers to access the information needed to review and remediate issues quickly. All vulnerabilities got triaged or remediated before the developers merged the code to a production deployment branch.
2. Don't overwhelm developers with irrelevant security scan results.
To keep developers focused, bring all scanning engines together in a single pane of glass, and deliver actionable vulnerability data to developers by filtering results and tuning queries to your organizational needs. Remember developers are your biggest internal customers for your AppSec solutions, and their adoption of tools measures the success of your program.
Some organizations see many results for initial scans of their projects. This open floodgate is common for applications with a history of releases that have never undergone any security scanning or review. Some organizations initially focus on a few high-risk types of vulnerabilities first to avoid overwhelming developers with remediation efforts. Web applications, for example, are often prone to Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and SQL Injection. DevSecOps teams may configure initial scans to limit detection to these vulnerabilities and, once fixed, configure subsequent scans to detect a broader range of risks.
3. Make sure new AppSec tooling comes with sufficient training
Suppose your Security team decides they need a code analysis tool and implements a successful Proof of Concept with an AppSec vendor. In that case, they can't simply send out an email to developers saying, "We're ready for you to start using it." The tool might have a steep learning curve, and developers will struggle to use it. Product training is only the basic introduction. AppSec teams need to show developers how to incorporate tools seamlessly into their workflows.
Some AppSec organizations work with Checkmarx Professional Services to initially pilot the integration of vulnerability scanning in the workflow of a few of their top development teams. Checkmarx Professional Services will then work with these teams to perform the initial triage of results, allowing the developers to understand how vulnerabilities work and how they manifest using their own code.
4. Work closely with developers
Don’t skip working closely with developers. AppSec teams often won't understand the architecture or purpose of the multiple types of code DevOps works on, leading to errors in risk profile with irrelevant scan results. AppSec specialists may theoretically understand how developers use security tools--they need to engage with developers to adapt their approach according to how developers prefer to work.
For example, an AppSec team started scanning repositories from the source control system without engaging DevOps. In theory, this would allow the AppSec team to review the results and identify the top priority issues. The AppSec team, not understanding the application architecture for all applications scanned, mistakenly identified some of the top issues related to mobile application development when reviewing a web application.
5. Adjust expectations around software delivery through education.
Finally, manage expectations around software delivery by creating transparency and awareness. Vulnerabilities may be detected through automated scanning but are only helpful if actions taken lower the risk imposed by the detected vulnerabilities. If the vulnerabilities and their potential risk are not visible to all stakeholders, developers may receive assignments to fix these bugs.
Organizations are implementing one very effective method to automatically open issues in the team’s issue tracking software for security vulnerabilities detected in automatic scanning. This integration streamlines scanning into the team Agile processes and creates a very transparent view into the risk introduced by detected vulnerabilities for all stakeholders. As a result:
- Developers could now track discussions related to triage and remediation effort estimations across all stakeholders and contributors.
- Project managers could assign remediation user stories during sprint planning due to the availability of effort estimations.
- Product managers could see issues and prioritize them appropriately, just as they would any other user story.
- Executives could view dashboards derived from the issues to assess risk and view remediation effort progress and how it affects release dates.
As transparency, communication, and collaboration increase, accountability becomes a key factor in prioritizing remediation efforts.
A Successful Shift into DevSecOps
Successfully shifting from DevOps to DevSecOps without deceleration requires strategic support and tactical changes. Organizations must aim for the right combination of senior-level endorsement, better visibility into security and vulnerabilities throughout the SDLC, and support for developers to adopt AppSec tools if they are to mature to a complete DevSecOps approach.
Which of these tips sounds most approachable to you?
If you’re not quite sure which you should tackle first, it would be helpful too first gauge how optimized your security practices are within our DevOps processes. Read more here.
