3 Annoying Security Speed Bumps on the DevOps Highway
Times are a Changin’
In the software engineering world, change is the only constant. In the course of the last decades, the frequency of that change has exploded.
What Agile has brought to software teams, DevOps brings to the entire organization. And the results speak for themselves. DevOps practices have amplified the speed at which ideas become reality. Companies that are DevOps high-performers are winning.
The future is already here — it’s just not very evenly distributed. - William Gibson
In parallel, Application Security was doing its own thing and the gap widened.
Security and development are perceived as opposing forces, with different mindsets. It doesn’t have to be like this. Security and development are better together. It’s only a matter of making security approachable and providing the right context. This is DevSecOps and enables businesses to move fast and be safe.
What 3 problems keep development teams from adopting AppSec?
1. Too Much Noise
Nowadays, there are too many distractions that are fighting for our attention. Security tools only add to these distractions. They find everything that could be a possible issue. Most of the tools running against your codebase produce thousands of results. Especially traditional security tools produce hundreds of pages of PDF reports. Have you ever been on the receiving end of one of those reports? Or even worse, the one responsible for fixing those issues?
Security is already intimidating enough. Let’s not make it worse by flooding developers with lots of security issues. Security tools have to report issues that have a high impact if left unfixed. Less is more.
2. Lost in Translation
Security experts have developed a very specific and unique language over the years. Terms like XSS, CSRF, SAST, DAST, iDOR, and LFI are clear for security experts. But if you haven’t spent a good part of your career in application security, these terms are confusing.
Imagine looking at hundreds of security issues with lots of cryptic details. Details about how attackers can abuse your app full of references that don’t make sense. But the key sections on how to fix the issues are thin. There is rarely any actionable, framework-specific content — if there is anything at all.
Let us use plain, easy language and give useful instructions on how to fix issues.
3. Bad Developer Experience (DX)
Security tools should be made for developers. Yet, most of them are designed for security analysts. And it shows in many areas, such as setup, user experience, and workflow integration.
They are difficult to setup and maintain. Often, teams of experts are required to onboard applications and fine-tune results. Even then, these tools exist in a silo and are not integrated into the development workflow.
Let us focus on the right audience. Developers should be able to embed security tools into their workflow in minutes.
Introducing GuardRails
We are a team of developers and security experts. Our mission is to empower development teams around the world to move fast and stay safe. GuardRails was started to achieve this mission.
GuardRails will initially be available as a GitHub application. In the beginning, we’ll help you secure your JavaScript repositories. Support for more languages is coming soon. Get in touch with us and tell us which language support you want.
