As DevOps (which means the unification of development and operations) continues to sweep the software industry, many organizations are questioning how they can operate more efficiently. Where can we save time? How can we increase (or, at the very least, maintain) software quality on a development schedule that seemingly gets tighter and tighter with each subsequent release?
The truth is that the answers to these questions lie in the culture shift that occurs when an organization makes a conscious effort to employ DevOps practices, rather than just embracing DevOps nominally without actually putting DevOps principles into action.
In this article, we’ll discuss one way in which organizations can put DevSecOps into practice. Specifically, we’ll focus on using DevOps to overhaul legacy security operations—in other words, to do what has come to be known as DevSecOps. DevSecOps practices must truly replace the legacy security mindset and implementation strategies in order to increase application security within a quicker, more agile development cycle.
Pre-DevSecOps: The “Old Way” of Doing Things
In some waterfall shops, application security can be treated as an afterthought—something to be handled after the development of the application has been completed. These legacy practices were similar to the older processes for testing software—wait until development of the application has all but wrapped up, and then have testers and security folks test the application for security vulnerabilities. Inevitably this would turn up issues with the application, and these bugs or oversights would be reported back to the development team to be rectified.
The problems with these practices are numerous. For instance, there is the issue of uncertainty. Utilizing this legacy approach to application security means that the organization has no accurate way to predict the effect of security testing on the release schedule. What if security testing turns up a major security vulnerability that requires a major refactor to provide a proper fix? This could all but destroy the delivery schedule, leaving both development and operations teams with unhappy customers and even less happy upper management. Situations like these are what led to the inception of DevSecOps as a solution to these woes.
The DevSecOps Difference
The philosophy that defines the idea of a DevSecOps organization is simple: Everyone is responsible for application security. So no longer does analysis of application security begin and end with the security engineers. Instead, it starts from day one with the software developers and continues throughout the entire development process with everyone involved.
DevSecOps requires security analysis and testing at all phases of the development lifecycle where it makes sense. The idea is simple: By beginning security testing earlier in the process and continuing to test at all phases throughout the process, you can enable everyone to make better application security decisions as an organization. This is due to the effect these processes have on assisting the team in finding security vulnerabilities earlier in the development lifecycle where the team will have an easier time getting to the root of the problem. As we all know, bugs are less expensive to fix the earlier they are found. In other words, it takes the development team less time to resolve an issue with application security if they can deal with the issue earlier rather than later (when development has wrapped and the issue is deeply woven into the application).
Putting DevSecOps into Practice
Aside from simply stating that the entire team is now responsible for application security, what concrete steps can the team take to make the move to a DevSecOps culture? Taking advantage of tools available for both manual and automated testing can help. At the development level, tools to analyze the source code of the application can help to discover issues within the code prior to their integration with the shared codebase. In addition, this will help the development team learn to write code that is more secure. Developers are often a quick study. After several iterations with their security shortfalls being pointed out, it’s likely the development team will be writing better, more secure code, thus preventing security issues from arising later in the process, and making the team more efficient as time goes on.
Another useful tip would be to establish and run test scripts that target potential issues with application security when building and deploying to test environments. If the test fails, then the build fails, and the application is not deployed. By enlisting this type of security integration testing, the organization will establish a base level of security in all environments, ensuring that avoidable security vulnerabilities do not make their way into a potential release candidate.
Automated tests of this nature will innately make your applications more secure while saving time on the backend of the development lifecycle due to the likelihood that fewer vulnerabilities will be discovered as the end of the development cycle approaches. As your organization matures into a successful DevSecOps organization, the team will have a greater sense of assurance that their applications are secure and that production releases will not be delayed.
Conclusion: Incompatibility in DevSecOps Philosophy
Legacy application security tended to lean on the backend of the development cycle in a way that endangered the release schedule. By waiting until the end of a project to analyze and test for security vulnerabilities, you end up finding issues that are much more expensive to fix than they would have been had you discovered them earlier. You also enable a culture of uncertainty regarding the level of security your application holds.
By embracing DevSecOps practices, quite the opposite can occur. DevSecOps practices inherently take the pressure off of the backend of the project timeline by making security a priority at all points in the development lifecycle. This enables the team to become aware of security issues early on in the process, saving time and heartache down the road. In addition, to the contrary of the older model where security analysis is held until the end, the DevSecOps model perpetuates a culture of confidence in the security of the organization’s applications. This is because with DevSecOps, application security is the responsibility of everyone involved and it is taken into consideration at all phases of the project.
For more, check out Twistlock’s Guide to Modernizing Traditional Security.
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
Twistlock Releases Serverless Runtime Defense
A few months ago, we wrote a piece on “The Continuum of Cloud Native...
Why DevSecOps is No Longer Optional
DevSecOps has been a hot topic within tech conversations for a few yea...
Better Together: Announcing The Twistlock Advantage Program
It’s been about three years since we exited stealth with the first g...
My Security Toolset Today Vs 10 Years Ago
It can be easy to forget how sophisticated IT security tools are today...
How to crash the Linux Kernel with a CDROM interaction – CVE-2018-11506
I’ve recently discovered and reported a buffer overflow vulnerabilit...