The modern security landscape is one of ever evolving threats and challenges. Modern software engineers, Ops, IT infra, and SecOps often feel like Sisyphus. Every day we push a boulder to the top of a hill, only for it roll back down and start again. For every day we send out security patches, we apply vendor patches only to find out that tomorrow is always 0-Day, and more issues will arise. Our sand castles forever wash away. The dejection leads to normalization of security breaches which is not what a responsible organization would want. This struggle we find ourselves as an industry in has no light at end of the tunnel. We are taught there isn’t, because there is in fact not.
The issue is fundamental, ideological if you will. We react to security issues. We may plan, we may test our plans (and one should), but we fundamentally react. No matter how good you are under pressure you are certainly worse when you are reacting to events. You are off balance, and off guard. So our actions, while a best effort, and while even according to the plan may not be enough due to no fault then our own. Stress is never good.
Let’s outline our modern security approach:
- Threat Models boils down to reacting according to plan.
- Dependency analysis software like Snyk, BlackDuck, and Github Security Alerts are all based around reacting to CVE’s/Issues in Open Source libraries. These tools shorten the loop for your developers to reactively upgrade versions and apply fixes.
- Anti-Virus reacts to malicious code finger prints often already running on your computer.
- Firewalls and Network filters are only as good as their rule sets generated in response to past threats and issues.
So how do we prevent security issues? Could we write an analysis tool to break code apart and peer into its very depths to see all of its current security issues? No that is surely impossible on an academic level. But its just crazy enough to work if you hired a few Ph.D.’s who knew compilers rather well and a handful of security engineers.
This is what Shifting Left is all about. No longer should we have Unit Tests, and Integration Tests to ensure code works. But now we have to add Security Tests. It is not enough that our code work, or even work correctly, but work securely. So you know ahead of time you aren’t leaking Customer’s health records to your logging stack, open to SQL injection, or running 30 webshells at the same time. You can catch these things before you even deploy.
If you let legacy code that does any of this into your run time you should be able to monitor and count every time it happened. If you application is hijacked by an attacker, you should be alerted, or able to set policies to remotely stop the application.
This tool exists. This tool is ShiftLeft.
This is a Security Bloggers Network syndicated blog post authored by Cody. Read the original post at: ShiftLeft Blog - Medium