DEVOPSdigest

As a security professional of course I'd love to see more security automation deeply integrated into the development process. Everybody knows since the 1990s that security as an afterthought just doesn't work, yet we keep doing it.

The reason, I think, is because it's very hard to automate security. So we'll start with the low hanging fruits as that's what your adversary will do (or does already).

DAST

DAST (Dynamic Application Security Testing): If you deal with websites, implement a web application scanner that performs authenticated tests on your site. It does require some work to set up, it's not just point to and URL and click start. You shouldn't believe vendors who say that. Better tools allow you to “teach” them how to use the web app so the scanner can navigate through every function instead of just dumbly crawling the pages. This is a relatively small effort from your engineers and the security team can fully monitor the results. Definitely a quick win.

SCA

Security Control Assessment (SCA): Next, or even in parallel, you NEED software composition analysis. That's the fancy name for 3rd party library scanning. You can have the best secure development process in place – if you only focus on code, what your engineers create, you're doomed. Everybody uses open source. And like every other code it has vulnerabilities. Most often with publicly available exploits. The good thing about SCA tools is that the false positive rate is very low as it uses the information included in the used libraries themselves to identify their version and then the tool checks if there are any vulnerabilities published for that particular version in the CVE database.

You need to integrate the SCA tool into the development pipeline, because libraries that do not have vulnerabilities today might show some critical flaws tomorrow – capturing them early on is your best chance.

In a similar fashion, you can significantly improve container security. While containers are typically dynamic and sometimes do not live long, it does not mean they are flawless or invulnerable. Look for a container-native solution to be able to do things like runtime vulnerability management, configuration baselining, checking for components with active CVEs, or active threat protection or even forensics.

SAST

SAST (Static Application Security Testing): Of course we must talk about static analysis. It is not a silver bullet for sure, but again it can pick those low hanging ones for you. Start with a relatively tight scope, critical findings for example and work backwards, opening the scope one-by-one. But don't even bother to do one-time scans, either integrate the tool into your pipeline or just forget about it and go work on something else. Don't try to enforce the rules (no matter how few you have) on the whole codebase, but DO apply them on any new code going forward as you can eliminate vulnerabilities early. The legacy part again can be worked on line-by-line, module-by-module.

DAST2

Once you have a webapp scanner in place and SCA is checking your external dependencies and you are doing SAST on any new code, then go back to dynamic analysis and get some protocol fuzzers and API testing tools.

IAST

IAST (Interactive Application Security Testing) is kind of a niche thing, but it is surely powerful: You have an agent sitting on your test environment instrumenting everything and seeing process memory will allow it to interact with the application and find defects in real time, fully automatically. Why not forget everything above and just do LAST? Because it's hard to deploy, needs extremely technical high touch maintenance. Nevertheless, it's the future and you should keep an eye out on this emerging testing technology.

So much about technology, let's not forget yet another very powerful tool, bug bounties. Integrating a bounty program into your development process will allow you to capture actual, exploitable findings and fix them in a timely manner. As always, start small, even consider a company internal program first.