SBN

How to cyber security: Invisible application security

Invisible application security is the concept of integrating and automating AppSec testing with little interruption to developer workflows.

Invisible application security | Synopsys

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.

Set-and-forget

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.

Give your developers a clear runway

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.

Invisible AppSec

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.

The coming Nirvana

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:

  • Different security tools produce different kinds of results in different formats. You need a way to combine, deduplicate, and homogenize results.
  • Application security is about managing risk. You need a way to triage and prioritize all your findings, so you can spend your time and money fixing the most dangerous findings first.
  • As you automate more security tools into your development process, you’ll realize that you probably don’t need to run every tool on every developer commit. You need an intelligent approach to orchestration so that you are running the right tests at the right time, making the most of your available resources.

An orchestration and aggregation system for security tools has another important benefit: as new security tools are adopted, automating them is easier.

The next generation of application security is dawning. You can be a part of it with Code Dx and Intelligent Orchestration.

ESG white paper: Cracking the Code of DevSecOps | Synopsys

*** This is a Security Bloggers Network syndicated blog from Software Integrity Blog authored by Jonathan Knudsen. Read the original post at: https://www.synopsys.com/blogs/software-security/invisible-application-security/