You may think that DevOps or DevSecOps doesn’t matter. If hearing the words DevOps or DevSecOps makes you think, “that doesn’t matter to me,” you’re missing the transformative happenings within the world of software construction. It’s a transformation that can decrease or increase the risk you carry. The choice is yours.
Software composition has been turned upside down in recent years. While DevOps became a thing in 2009, most organizations took at least a decade to realize that this new methodology was available for software delivery. DevOps eliminated developers creating something and tossing it over the wall to the operations team with a message of “good luck.” DevOps brought both functions together in a partnership to build software that runs flawlessly in production.
DevOps also introduced the idea of software delivery pipelines, like a subway map, with new source code injected on the left side via a pull request. The code, or build, is then run through various automated tools along the line, assembling the code and all the components into an artifact that can be executed in production.
The introduction of DevOps presented a challenge — security was not integrated from the beginning. DevOps,a continuous delivery mechanism, did not consider security as one of the initial goals. As a result, DevSecOps began to generate attention on the Internet in 2016, as engineers focused on adding security tools to build pipelines.
A software factory applies manufacturing ideas to software development. There is a need for your software factory to become a secure software factory. To transform your software factory and lower your software factory risk, apply these four DevSecOps focused tips.
- Integrate application security tools that add value to your developers.
Application security tools include Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST). SAST searches the source code written by developers to identify issues for fixing before the build makes its way to production. DAST runs a series of security tests against a running application instance.
Other tools were added to pipelines to continue to strengthen their security stance. Software Composition Analysis (SCA) identifies vulnerable software components, while Container Vulnerability Analysis (CVA) determines vulnerabilities in the running instance of the application in a container in the base operating system or system configuration.
Application security tools add value to your developers when they have a high degree of fidelity. Each tool generates results; if not correctly tuned, the results can overflow the developers. To avoid this, tune these tools to ensure the developers see the value of the tool suite.
- Educate your software developers about application security.
Application security knowledge is not something that your developers learn in university. Most university programs do not even discuss security, let alone instruct your developers on the details of the OWASP Top Ten application security risks.
You’ll lower software vulnerabilities by providing your developers with a solid application security education, resulting in more robust products and happier customers. Focus on transferring knowledge and hands-on experiences for developers, where they are challenged to find and fix security issues in sample applications.
Ongoing security education teaches developers and others in the SDLC to spot vulnerabilities early in the process. Security-first thinking is a culture shift that should align with your overall security goals.
- Measure the security levels of your software factory using the OWASP DevSecOps Maturity Model (DSOMM).
It’s helpful to have a measuring stick for any process improvement. The OWASP DevSecOps Maturity Model (DSOMM)provides opportunities to harden DevOps strategies and shows how these can be prioritized.
With the DSOMM, you work with your DevOps team to assess the security state of your software factory/build pipelines. After evaluating, you plan to increase the security of various deficient areas.
- Secure not only the code in the pipeline but secure the pipeline itself.
If you pay attention to news on the Internet, you know that the software supply chain has become a particular area of concentration for attackers. It acts as an input to your software construction process, making the deploy build systems prime targets.
To protect the software factory, protect the build pipelines by ensuring they are resistant to the most popular attacks. See the Top 10 CI/CD Security Risks project for a detailed dive into the top ten risks.
Conclusion
The delivery of software has changed drastically in the past ten years. The cutting edge is DevSecOps, and to lower the risk of your software factories, look to deploy the right application security tools, train your developers about application security, assess and improve your approach using the DSOMM, and secure the pipelines themselves.
By investing your time, attention, and resources into the security of the software factory, you can lower risk by building a software delivery process that speeds up delivery and results in a more secure product for your customers.