Invisible application security is the concept of integrating and automating AppSec testing with little interruption to developer workflows.
I really love the keyless entry system on my car. The “key” is not a key in the traditional sense; all I have to do is put it in my pocket and forget about it. When I reach for the car door handle, it simply unlocks. When I leave the car, I wave my hand over the handle to lock the car.
This is nice because I don’t ever have to take the key out of my pocket, which lowers the risk that I will accidentally leave it somewhere or lock it inside the car.
But better yet, I don’t have to think about it. The car is locked until I need it to be unlocked.
This is a variation on set-and-forget, one of my favorite principles. If I’m going to spend time and money to fix a problem, I would like it to stay fixed.
For example, I have rain gutters at the edges of my roof to catch runoff. Unfortunately, these gutters also fill up with pine needles from nearby trees. I can solve this problem by clearing out the pine needles and other debris, but I’d have to do this at least once a year.
Instead, I can install a system that allows water into the gutters but not pine needles or leaves, which means I never worry about my rain gutters again.
Software developers also want things that just work—they want problems to stay fixed. They like clear definitions and cleanly delineated responsibilities.
From this standpoint, the first generation of application security was a special kind of Hell. Application security testing was performed very late in the software development life cycle (SDLC), typically just before release, when the development team thought they were done.
Security testing usually produces a very long list of findings, which might or might not be real problems, and which might or might not make sense to the development team. They thought they were finished, so they were frustrated by having a big pile of findings thrust upon them without necessarily understanding the implications.
In this first generation of application security, security teams were also frustrated. They worked hard to run security tools and were usually swamped with testing demands from all the development teams in an organization. Furthermore, many development teams, under time pressure to release products, might minimize or ignore the issues reported by security teams.
In the second generation of application security, development teams could automate and integrate application security testing into the development process, creating a much smoother experience. Security teams, instead of scrambling to preform security testing for teams that don’t always appreciate their efforts, work as advisors and mentors to development teams.
In this second generation, developer workflows are minimally disrupted. When application security is automated into existing build and package processes, developers don’t have to think about it. And when application security results are integrated into existing issue-tracking systems, developers can work through security issues just like any other functional issues. Application security is a crucial part of the development process, but it fades into invisibility in a very positive way.
A new generation of application security is happening now. If you have successfully transitioned to the second generation of AppSec, you have some new challenges to wrestle:
An orchestration and aggregation system for security tools has another important benefit: as new security tools are adopted, automating them is easier.