The speed of business is constantly increasing. To keep up, organizations have started to develop and release new products, websites, and apps at breakneck speeds. This quickened pace has shifted the way web applications are developed.
Development software now needs to seamlessly integrate into other tools, so there are more APIs, and because we want to release apps faster, we’ve moved to a micro-service architecture. These are both fantastic ways to switch the paradigm of development, but there is concern that, as we move quicker, the security of these new innovations doesn’t keep up with the speed at which they are built. The more rapidly companies release code, the faster they release potential vulnerabilities that nefarious threat actors can exploit.
Our industry cannot forget about the security of new applications. Recently, we tested a number of “API first” applications and noticed a disturbing pattern. Simple vulnerabilities -- ones that should never be present, like being able to view another user’s data by simply using my API key and changing the value in a parameter -- are everywhere. These are threats that shouldn’t be on the table.
Why do we see this happening now? One factor is that APIs are new to many developers, so they’re unsure of how to write secure code for them. In that case, however, the security side of the house should catch these issues and fix them before release. What we’ve seen, though, is that security teams are relying on their normal assessment cycles to test these applications, and those methods don’t work with this new system. APIs can’t be easily scanned by a traditional black box scanner, which makes it seem like there’s no vulnerabilities, but in reality the threats are likely there, the APIs just haven’t been tested thoroughly.
What’s an organization to do? The key is to look at the three teams that deploy web applications. First, we have the developers. They write the code and have urgent deadlines that can’t be missed, so they are incented to get as much done as quickly as possible. Second, there is the security team who checks the code for vulnerabilities and maintains the security of the running code in production. Lastly, we have the operations team who ensures the systems remain stable.
These teams have different priorities. Developers are paid to get code out quickly, but then security is frustrated because the code isn’t written securely, and once a vulnerability is found, security has to go back to the developers and get them to fix the issue. And since the mission of most organizations is to get code out rapidly, this makes security the evil gate keeper that says “No, this must be delayed until it is fixed.” Developers are then frustrated that their code is being held up. The operations team is tasked with maintaining the uptime of the system, which makes them not want to change anything if they’re already working with something that’s stable, even if it may have a vulnerability, because changing code may cause it to fail stability tests, which will also hold up the release.
What’s the fix? We’ve seen a growing push to integrate these different segments into a single team: DevSecOps, with a mission to release fast, secure, and stable code. There are no competing priorities; instead, there is one goal and the responsibilities are shared. Developers can access security tools and training as they’re writing applications, making code more secure before it’s checked for issues. The security team can prioritize vulnerabilities for the developers to make sure code is secure before it’s released, and operations integrates into the development team to make sure the code that’s written is stable from the beginning. Testing for all teams can be automated as the code is being written, making everyone’s lives easier.
It sounds too good to be true, but it really does work! We’ve seen the results. There’s a dramatic drop in the number of vulnerabilities and the “time to fix” issues that are found. According to statistics from the 2017 Application Security Statistics Report, about 15% of vulnerabilities from traditional code development are fixed within 10 days of finding them. Compare that to the stats of a DevSecOps company, which fixes 53% of vulnerabilities within 10 days.
The only catch is that the entire company must be onboard with a DevSecOps approach. There needs to be investment into developer training, automated security and release tools, and integration into the current development process. But these investments result in fast, secure, and stable code that can be rapidly developed at the speed that consumers demand, without the vulnerabilities they fear.