Your AST Guide for the Disenchanted: Part 1
At ForAllSecure, we’ve observed an increasing uptick in organizations looking for alternatives to mainstream application security tools. Why? Organizations are finding that today’s AST tools aren’t servicing their objectives to develop software faster and deploy frequently.
In this blog series, we’ll chronicle the top challenges of incorporating application security testing in DevOps workflows. We’ll also unpack how organizations are addressing these challenges.
How DevSecOps Came To Be…
DevOps is mounted on automotive’s long standing “lean manufacturing” philosophy and aims to deliver applications at a rapid, iterative pace to keep up with cloud, what was then a relatively new deployment method synonymous with agility, flexibility, and scalability.
Speed though came at the cost of quality. This isn’t to imply that quality was intentionally neglected. It’s a natural consequence that came with agile frameworks. However, as software permeated practically every aspect of business, nefarious actors saw these data rich software as easy targets for financial-gain, personal recognition, and schadenfreude-inspired amusement.
Organizations quickly came to realize that quality could no longer be ignored. The advent of security as a software development discipline came with its bouts of kicking, screaming, and groans. Despite today’s intense fascination with software security, security teams commonly face passive-aggressive opposition, because security requirements, though altruistic in their mission, are notorious for “slowing down” development and releases.
According to DevSecOps Realities and Opportunities by 451 Research, “46% of participants cited that the noise of false-positives drown out the benefits of security scanning and other elements in CI/CD processes. [They] believe that organizations can help address this issue by choosing security software and services that specialize in effectively reducing false positives and the noise that comes with them. In SAST, for example, this will likely require writing custom rules tailored to the organization’s technology stacks and software.“
Software Security is Simple?
Developing secure applications boils down to the basics – make sure the code you deploy is free of security bugs. Sounds simple enough in principle. However, this has proven that deploying bug-free code to be a much more difficult proposition in execution, especially with application security testing 1.0 tools, such as SAST:
- Detection: Application security testing tools help quicken the vulnerability detection process. In initial demos, organizations are amazed to see how many defects these tools can flag. Only after purchase do these organizations realize that several of these finds are false-positives. When security teams are presented with an unorganized list of defects ranging from high impact to low impact — and a generous sprinkle of false-positives in between — productivity comes to a grinding halt.
- Validation: As a result of false-positives, validation must occur. Validation is largely a manual effort conducted by security teams, where they validate findings from application security testing tools. By weeding out the false-positives, these findings become much more actionable for developers.
Remediation: Now that the defects are sorted, they can be passed off to development, where they can be fixed and the software can ship immediately, right? Unfortunately, these defects merely tell developers there’s something wrong with their code. However, it fails to share the more important information: what, how, and why. Actionable? Not so much.
The Cost of Application Security Today
Application security requires human intervention across multiple teams. As you can see from the workflow above, each vulnerability must be handled 3 times before it can (sort of be) driven to action! A day lost here and there adds up. How much time? Here’s what our market research revealed:
According to WhiteHat Security and Ponemon research, 222+ work days are lost to vulnerability remediation. It’s obvious why organizations avoid it. You can’t justify a security practice that has a direct impact on the bottom line and places strain on precious development resources and time.
The social impact of DevSecOps is ironic, don’t you think? In our mission to…
…introduce complexity to a process (from DevOps to DevSecOps)…
…we are left craving simplicity.
…spread the manual effort of security testing…
…more previous resources and time are wasted on manual testing and inter-organizational coordination.
…have everyone own security…
…no one wants to own it.
Getting to the Root of the Issue
Gartner has cited that in order for DevSecOps to truly work, application security must support the following:
- Automation: Current vulnerability management approaches rely on humans to propel the process forward, requiring manual verification that it’s ready for the first step. The next iteration of application security must be more hands off.
- Integration: Integrating directly into developer environments mean less context switching for the developer, ensuring they remain focused on developing
- Speed: Development velocity and deployment frequency is at an all time high. Security testing has to be able to keep up with these paces without introducing slow-downs.
Gartner’s observations echo ours. However, these are symptomatic problems to a larger root issue: inaccuracy. At ForAllSecure, we posit that by addressing this one technical limitation in today’s application security testing solutions, we can finally take security where it needs to go.
Until next time…
In this post, we chronicled the challenges of application security as a part of DevSecOps workflows. We’ve also unveiled the one application security testing limitation that’s blocking organizations from attaining a true DevSecOps process.
Stay tuned for the remainder of the series, as we dissect how accuracy is an enabler for DevSecOps. Meanwhile, read how to get started with DevSecOps. For immediate information or a demo, contact us at firstname.lastname@example.org.