In response to market and competitive forces, many companies have turned their attention to developing higher quality and more secure software. Whether that software is their product or is a component of their product, quality and especially security have become required vs optional. To accommodate the security requirements, some companies have adopted DecSecOps overlays to their software development process that can and has caused significant disruption to their process. This blog series is aimed at helping to understand how the transition to DevSecOps need not be traumatic and that a cautious approach that leverages state of the art tools and techniques can be helpful. Consider this blog series a practical approach to DevSecOps.
This post discusses a practical approach to transition to DevSecOps by starting small to help ease your way into DevSecOps. Click here for the other posts in the series.
Easing Your Way into DevSecOps
Transitioning to a more secure software development process across an organization rarely works when done with a “big bang” approach. There’s often lack of buy-in from the teams and general resistance to change when new approaches haven’t proven themselves. The cultural barriers to adoption remain and the initiative fails. As with any large task, it makes sense to start small to learn and adapt before expanding to more teams. The move from DevOps to DevSecOps should be organic.
Start Small
The alternative to the doomed “big bang” approach is to start with a small motivated team starting a new project where it’s possible to implement new practices from the very beginning. By keeping the scope of the project smaller in both technical and business risk it is possible to allow time for learning and adjustments along the way. Think of this as an incubator project where the results are analyzed and used to evaluate gains, losses, what went right and what went wrong. This team can learn and then teach the organization what works and what doesn’t. Importantly, they set the standard for how to approach DevSecOps and kick off the organic growth needed for a smoother transition.
Starting small extends to the use of new tools as well. It’s one thing for a small team to adopt new technologies but they can be quickly overwhelmed. SAST tools can product a lot of information. It’s important that initial projects concentrate on high-impact, high-probability vulnerabilities first and foremost. Tools such as CodeSecure CodeSonar provide the tools necessary to help users focus on the most important warnings. It’s easy to get bogged down in the details and discipline is needed to focus for the highest impact and to get the most ROI out of new tools.
Start at the Beginning (or as early as you can)
This is where “shift left” plays an important role in the transition to DevSecOps. A small team can introduce new techniques without a large initial impact on productivity. They can also start integrating security from the beginning, right at the concept phase of development. They can introduce new tools and become proficient at using them. It’s at the early stages where the payoff is the greatest. Finding and fixing possible vulnerabilities and adopting more secure design and coding practices greatly reduces the downstream impact. It’s not hard to justify the effort when security attacks and data breaches in production systems can cost millions in fixes, downtime and reputation.
Measure Success
The interesting thing about measuring DevSecOps success is looking at what isn’t there; security vulnerabilities and potential software weaknesses. To understand how well a new DevSecOps transition is working it’s important to have a baseline of vulnerabilities that exist in your other applications. For example, how many vulnerabilities were discovered during security testing? How many vulnerabilities made it into shipping products? If these are known, then it’s a case of measuring how well the new project does versus the baseline performance.
Other metrics are important too such as measuring the number of vulnerabilities detected, those that are true risks, and those that were removed through corrective action. SAST tools provide information on a per-build basis so it is possible to look at trends over time. You can evaluate the DevSecOps process in terms of vulnerability trends over time, are they converging to a goal? How quickly is the convergence?
The ultimate measurement of success is a more secure product and, ideally, security testing at the late stages of development should find less and less vulnerabilities than in the past. After building in security, starting at the beginning with a shift-left approach, vulnerabilities are caught sooner and removed.
Start your DevSecOps Transition
The critical time to detect new security vulnerabilities is as soon as developers write new code (or test cases) before it’s submitted to a build or software control system. It’s also critical tools work in your favorite development environment (be that VI, Emacs, Microsoft VS Code or Visual Studio, or any of a number of Eclipse based environments). It’s at this point where SAST tools shift security improvement via automation to the earliest point in the development cycle. Finding and fixing vulnerabilities here is less risk, cheaper and easier.
Equally critical is establishing an initial baseline inventory of your third-party software assets whether that is open source, reused internal code from other projects and third-party commercial software. This is done at the very beginning of the project, about as shift left as it gets. SCA is critical throughout the development process since the open source and third party software that you depend is likely to have updates new security threats over time (including after you release the product!)
Below are some of the benefits of early adoption of SAST and SCA tools as part of your DevSecOps adoption. These tools used in conjunction with a security “built in” approach make this transition easier:
- Improve security awareness by exposing vulnerabilities in existing code, third party software and newly developed code. SAST tools like CodeSonar provide all the necessary information to fix potential vulnerabilities but also an explanation of the severity and risk. Developers get more experience with the types of software weaknesses that lead to vulnerabilities and learn to avoid them.
- Illustrate ROI by measuring success and have a goal in mind. Eliminating one serious vulnerability justifies much of the investment. However, communicating this ROI is important and needs to be in the context of how costly and risky vulnerabilities are once a product is released.
- Remove gatekeeping so that developers and the security team are working together. Security teams provide the security controls that developers need to follow with a “trust then check” approach. Developers learn more about secure practices over time and integrate it into their existing workflow. In the end there is no security team gate at release, all members of the team know and understand the state of the product.
- Integrate security practices into software development gradually starting with a small team and small project. As experience is gained these teams train the rest of the organization on best practices.
Summary
DevSecOps is a way to build in security into an application and the transition from an existing CI/CD and DevOps process is made easier with right approach. Successful transition depends on breaking down the resistance to security practices that exist in many organizations. A start small and start early approach is recommended where new techniques, processes and tools such as SAST and SCA can be integrated with less downtime and cost.
Most importantly, you need to decide what the success factors are. Measuring success and the ROI of the effort is needed to grow DevSecOps organically within the organization. Tools and automation provide the data needed to show progress but communication the ROI needs to be in business terms. In the end, success is a more secure product and reducing your company’s exposure to data breaches and cyberattacks.
