The following is a work of fiction. However all the solutions are real things I’ve attempted in my time as a Cloud Consultant. Image this, you’re minding your own business when an empowered developer pops out of nowhere. They need to get an application deployed. You begin to open your [...]
Recently a friend of mine told me his company, in an effort to improve security, was launching a bug bounty program. I’m a huge fan of bug bounty programs, hiring professionals to test your code is a great way to find things you may have missed and lets your clients, employees and investors know that you take security seriously. I asked him about his company’s reasons for doing to, he talked about protecting data and keeping their systems online but also mentioned that by outsourcing the bug finding they hope to save developers time and be more efficient. This shocked me, pentesting and bug bounties, while important, are the most expensive and inefficient part of the software development lifecycle.
The most expensive time to fix any software bug is after it has been in production. Refactoring code means you have to remember what you wrote, or decipher what someone else wrote. It means you have to be careful not to break anything. It means you need to push back improvements you’ve been planning and tech-debt you’ve been meaning to take care of. Paying per vulnerability is expensive too. Imagine paying a fee every time your linter discovered something, or every time a test fails. It’s inefficient, if the researchers don’t have access to your source code or your developer’s expertise, it may take them hours of research to find something that someone with full insight could have found much more quickly. It’s far better to tackle vulnerabilities with a devops mentality. To save time and money, you should shift left, discovering vulnerabilities as early as possible though scanning, linting and training in secure development at all levels.
If your application is public facing, congratulations, it is likely already being scanned. If your application or infrastructure runs on a popular platform such as wordpress (or windows) bots are actively looking for vulnerabilities to infect you. Sadly, unless something breaks you’re unlikely to know what’s being scanned for and what was found. Companies would be wise to scan their environments, both in production and non-production. Production scans should be less intrusive than their non-production counter parts. By scanning your pre-prod environments you’ll be able to catch certain vulnerabilities before you deploy.
Static and dynamic code analysis can find both obvious and obscure vulnerabilities at a fraction of the cost of employing people to do it manually. Like most software testing, the best time to run these tools is all the time. You can build linters in your CI/CD workflow and trigger them on commits, you can even have them run when a developer saves a file. One project I’m on has even installed IDE integrations to catch potentially vulnerable code before the developer even finishes typing it. Like the scanners, there are many tools that offer this functionality, ranging from open source to enterprise level.
Shifting further left, training and educating developers, architects and managers in secure development will allow for vulnerabilities to be squelched even before writing a single line of code. Employees can be educated on techniques and tools relevant to their position and security can be top of mind while architecture the application and even when writing the requirements. Catching and remediating vulnerabilities is best done as early in the development process as possible. Scanning your application regularly, testing your code and training engineers and management in security best practices will help make your code more secure while saving you time and money. Perhaps there will be a day when all security problems will be solved and we won’t have to worry about it. Till then, it’s best to scan early and scan often.
This post was originally published on runascloud.com
As a consultant, I tend to work with a variety of clients and teams all across the product maturity spectrum. Some are just starting; maybe they have an MVP, maybe ...
