The Impact On Security Testing For Devops-driven Applications

According to the Splunk/Puppet’s 7th annual report on the “State of DevOps”, 51% of software development companies worldwide already work with their DevOps team. In contrast, the release-oriented software based on the waterfall model is slowly losing its importance. The most progressive companies in this sector publish several hundred (micro)releases per month. [Next: An unvarnished inventory]

DevOps improves the classic approach to security testing that was practiced in the past: after Dev before Ops. DevSecOps seems to be the right method – at least because it includes security in the process. Unfortunately, it doesn’t go on as simply as that. DevSecOps is strongly dependent on the respective toolchain to ensure development quality (security as a non-functional requirement is a quality aspect of software). The problem is that people usually rely too much on a tool and stop thinking for themselves.

When using security testing tools aks yourself if you have the resources to use them all properly? These very powerful tools need to be fine-tuned so that they can be used for the developed application: you have to consider the frameworks, the CI/CD-chain, the coding style, the technology, the integration of legacy systems, the IDE platform and countless more.

Be aware that problems arise and evolve in unexpected ways, while at the same time you must always be vigilant and cautious and be alert to emerging threat patterns. So, make sure that you buy your DevSecOps tools with appropriate support from the manufacturer or even better an experienced application security consultant.

Although the security testing tools are very powerful, their positive effect is lost if they are used incorrectly. The whole thing could even backfire if, for instance, you confront your developers with thousands of false positives, the acceptance of security measures will drop.

Security does not work according to the big bang principle

Instead of doing a lot of things at once and not doing any of them right, choose a slower approach: first, develop a testing method and start with only one class of vulnerabilities – even if this doesn’t allow you to exploit the full potential immediately. Give your teams the chance to grow into a solid and professional review process. Integrate the results directly into bug tracking tools, source code management systems (SCM) or your general development environment. Please don’t waste your time with PDF reports.

Between black and white

Let’s concentrate a little on the DevOps phase of the “monitoring”. This phase should not only monitor what is happening in the application, but it should also be extended by selective, recurring security tests. In this way, the results of the tests can be optimized by specifically identified vulnerabilities.

But when is it useful to use it? As soon as the developed application is ready for use. Up to now, a large pentest in various forms, from black box to white box tests, was used in the course of acceptance instead of continuous checks. Usually, this happened after dev and sometimes before ops, but let’s be honest: usually after a few weeks of ops…

The procurement process from the tender to the order to the actual start of the pentesting project can take quite a long time and cost a lot of valuable test time and ultimately test quality. Since testing cannot guarantee the absence of errors, the budget for a pentest is almost always determined by a timebox (even if your pentest provider tells you otherwise).

For the love of reports

This timebox usually covers everything from project setup and management to reporting and editing – to name just a few services. And note: the smaller the timeframe, the higher the proportion of administrative work. But once all the necessary steps have been taken and the testers have completed the paperwork to access the scope and valid user accounts, they can finally do what they do best: put the software through its paces.

Finally, a dedicated report is produced – in PDF format, of course – which is a pain in the neck for all concerned: The auditor has to write the report and the customer is condemned to read it too, he is almost morally obliged to do so.

Then the tedious process of fixing the security problems begins: All is tested again, followed by discussions on how to report, before debates start on how the new findings got into the application during the re-check (this list can be endlessly extended). So in the end, you invest a lot of effort in obtaining, coordinating and evaluating a pentest.

Maybe the time has finally come to take a different approach – one that works much better with DevOps?

What can I do to reduce the administrative effort of a pentest?

The main arguments for DevOps are speed and flexibility. Why should we not use these qualities to increase application security as well? Why not regularly perform small pentests embedded in the developing process of the application? The only question is: In which iterations does this make sense? Maybe not only regularly, but even continuously? Or let’s just say continuously.

Continuous testing fits perfectly with DevOps. If you can’t or don’t want to hire someone full-time to test your app permanently, you can plan your tests every 2, 3 or 4 weeks – depending on what your budget allows.

What if my application goes live before testing?

Depending on which test pattern you have chosen, the continuous approach would not leave your application untested for more than a month. But let’s face it, unsafe applications have been exposed for much longer and you haven’t had the benefits of Continuous Integration/Continuous Development (CI/CD) to correct just a day or two later.

What if there is nothing new to test?

Let’s assume your developers are on vacation for two weeks and there is no development going on right now, so there is nothing new to test. No problem! Let the testers re-examine the existing code. A pentest always takes the easily identifiable security holes first – in other words, the “low hanging fruits”. Now give the testers the extra time to go into more detail and try different angles to find the non-obvious vulnerabilities. Or give them time to poke around in the one hole where they suspect problems, but they haven’t had time to look into it

Also, keep in mind: frameworks and their security tend to be eroded. Basic components and complex attack vectors also deserve closer examination after the obvious vulnerabilities have been identified. Give the pentesters that extra time to dig deeper. It will pay off.”

Interconnected world

Remember that you wanted to use DevOps because of the speed and agility. And you wanted to improve collaboration between the different roles throughout the development cycle. Forget the nonsense of having your code reviewed on site. The SEC Consult Vulnerability Lab regularly evaluates code remotely without compromising application security. Regardless of this, your developers are usually scattered all over the world and organize themselves with web conferences, chat, messenger, etc. And in the end, your application’s code is released into the wild anyway.

Don’t shoot the messenger

It would be crazy to think that the work of security experts would create gaps in your applications. These vulnerabilities already exist (because your developers have placed them there – accidentally, hopefully) before the pentest starts. This means that there is as much or as little potential “danger” from “remote” developers as there is from security experts testing remotely. Pentesters find what is to be found.