DevOps has evolved over the years and is essential to the success of many organisations efforts in build and deployment. The evolution of Security in Devops is critical, and holds the basic principle of considering security from the start, and throughout the development process.
We put the Sec first because we think security is kind of important, so we shifted it left.
Security is often considered ‘too little too late’ as seen from the perspective of the penetration tester and ‘too slow, too expensive’ from the perspective of the product delivery team.
Of course, longer term Security will become as much a part of the DevOps cycle as any other element. There is a bit of work yet to be done to convince everyone this is the case, and that it's not something we can leave for later, leave until we are ready for live, or worse still, once we are Live and already have thousands of customers using our products.
Thankfully security testing is coming out of the shadows, although in some quarters there is still the notion of the penetration tester as being the hacker in a hoodie stereotype, who rolls in at the last minute before a project goes Live, works their magic and throws a spanner in the works by giving the project team a Critical vulnerability to address.
Leaving the testing this late is a recipe for disaster.
Obviously, this scenario needs to avoided. The objective should be to mitigate finding critical security issues late in the day by actively considering security from the start and to test over and over that there haven’t been any issues introduced over time.
How can we give a continuous Security perspective?
Automate where possible.
A major principle which DevOps already makes extensive use of (automation), should be applied to Security.
Unit and Functional test automation is a mature and well accepted approach, which done properly can massively improve test coverage over shorter periods of time. The same principle can be applied to security.
There are now many useful tools which can be used to automate basic security tests, doing things such as port scans, automated code reviews, checking libraries being used for known vulnerabilities and so on.
When we are changing code frequently and building and deploying daily / weekly, we cannot rely on penetration tests which are scheduled weeks in advance and performed manually. They might find the issues, but you will then be unpicking 10 builds since the last test to work out where the vulnerability was added.
We need that automation speed and repeatability.
Shift left - It saves money.
If you are in the midst of a delivery and trying to convince everyone that security needs to be looked at as early as possible, it can always be useful to quote the cost of how much fixing a defect grows incrementally as we get nearer to Live.
The rub when it comes to security issues are that when found in Live they attract significantly larger costs to resolve, in many instances, than a functional issue, and are compounded by possible reputational impacts to businesses. If your system was compromised and you lost customer data for example. GDPR, ICO, newspapers, remediation, compensation, fines = nightmare!
In other words, if what we are building has the potential for security vulnerabilities, and we have to assume that they do, then there has to be an investment in security. Quite simply it could save your organisation a lot of money longer term.
Shift Left - It might win you the contract
Aside from pure security considerations, there is a commercial aspect to building in Security to your processes early.
Tender / procurement processes now routinely ask about plans for security from the start, and will want proof that you have considered this in your project for the piece of work they are considering commissioning you for.
You can bet your client will have security high on the list of their priorities. i.e. ‘prove to us nice and early that security is inherent in your process’.
At the End..
When we are ready for market with our product, web app, or whatever it might be, we still have the issue of security. It doesn’t stop at go Live. Earlier security tests, which I mentioned using automation to speed testing and enhance coverage, does not replace the need for a proper penetration pest by a qualified and experienced penetration pester close to Live and then on the Live infrastructure.
As good as some of the modern toolsets are, and as good as your automation might be, there are things which scans will not catch.
There will then of course be major and minor version changes, changes driven by legislation and so on, all of which will no doubt come with a level of urgency from a delivery perspective. An organisation who has a mature approach to continuous security testing will avoid letting one of these expose their business to the bad guys.
Security into DevOps will become the absolute norm, and whether the term SecDevOps continues to exist longer term or not, the principle of considering and actively adding Security right from the start of the process is the aim.