What is application security?

Application security, or “AppSec,” refers to the tools, processes, and best practices that organizations use to manage and prevent vulnerabilities in applications.

Digital applications are the foundation of our world, from managing bank accounts to accessing healthcare. At the same time, their increasing use and importance has turned them into prime targets for cyberattacks and malicious actors—resulting in devastating data breaches. The majority of recent security attacks can be traced back to weaknesses in the application layer. Application security (AppSec) involves the measures organizations take to address and prevent these potential weaknesses in their software. It can look like anything from simple risk awareness to a well-established security process with application security policies, including automated scanning and testing tool.

Why application security matters

Organizations don’t intend to deploy risky code. Security issues often get into codebases on accident, or simply because of the way teams build software. Many applications are built on open source: Free, reusable code created by a worldwide developer community. But when you build on open source components, you also inherit the potential security risks that come with them. These are known as vulnerabilities, or problems in a project’s code that can be exploited by malicious actors.

Learn more about open source security

Is my code vulnerable?

Let’s take a look at the numbers. Based on Veracode’s 2020 State of Software Security report:

  • 76% of applications have at least one security vulnerability.
  • 50% of reported security vulnerabilities are still unresolved six months after they’re discovered.
  • Almost one-third of applications have more security flaws from third-party libraries than their native codebase,

All added up, chances are high that your applications are at risk. It’s not a question of if you have vulnerabilities. It’s how many and how you plan to fix them—a challenge faced by every software team today. While resources like the CVE Program, National Vulnerability Database, and GitHub Security Lab work to limit application security vulnerabilities in open source code, even the most popular AppSec providers regularly evaluate their third-party dependencies and fix vulnerabilities in their codebases.

Learn how to evaluate your AppSec health
The sooner we can catch vulnerabilities and product issues, the better it is for the company in the long run.

James Hurley // Director of Developer Services

Common application security tools

Like DevOps, teams leverage automation and security tools to test and evaluate code at different stages of the development process.

Static application security testing (SAST)

SAST uses application source code or binary code as input, and scans this code for known vulnerable code patterns to generate results that identify potential vulnerabilities.

SAST stack

Code scanning and secret scanning with GitHub Advanced Security, Checkmarx, Veracode, Fortify

Dynamic application security testing (DAST)

DAST examines a target application’s code to identify its attack surface, or application tree, and deploys the application in a test environment to run simulated attacks.

DAST stack

OWASP ZAP, Veracode, WhiteHat

Passive and active integrated application security testing (IAST)

IAST finds security vulnerabilities by installing an agent which runs alongside the target application, either applications running in testing environments (passive) or applications running in live environments (active).

IAST stack

Contrast Security, Acunetix, Checkmarx IAST, Synopsys Seeker

Runtime application security protection (RASP)

RASP involves installing an active agent on a running application and using this agent to protect the application at runtime.

RASP stack

Contrast Security, Micro Focus

Fuzzing (or fuzz testing)

Fuzzing uses automated or manual methods to provide invalid, unexpected, or random data as inputs to running applications in a test environment.

Fuzzing stack

OWASP Zap, BurpSuite, Synopsys Defensics

Software composition analysis (SCA)

SCA analyzes an application to determine its third-party components, frequently focused on open source software (OSS) security issues and license compliance.

SCA stack

Dependabot and dependency review with GitHub Advanced Security, Snyk, Whitesource

Penetration testing

Penetration testing involves automated and manual tests that aim to test the security controls of running applications.

Pen testing stack

Nessus, Wireshark, OWASP Zap, BurpSuite, Metasploit

Bug bounties

Bug bounties are crowd-sourced security testing programs which leverage individual security researchers who get paid based on the vulnerabilities that they discover.

Bug bounty stack

HackerOne, BugCrowd

We want to make sure that we have our security controls baked into our pipelines, all the way from the first line of code you’re writing.

Miguel El Lakkis // Chief Information Security Officer

Comparing approaches to application security

Application security looks different from team to team, but the most effective approach starts in one place: The developer workflow.

Organizations typically implement security tools one of two ways: As a final step or “gate” in the development process or integrated throughout the software development lifecycle. However, unless security issues can be identified and fixed by developers early in the development lifecycle, technical debt will continue to be a challenge.

Traditional approach: Security as a gate

Having security as a gate is a popular approach often used by organizations new to application security. Security teams or third-parties run a single test or series of tests during the quality assurance phase, then deliver findings to developers in bulk to be fixed before production. This can cause delays and developer friction because of late security feedback, false positives, and manual reviews.

End-to-end approach: Security integrated into every step

Organizations that are more mature in application security use an end-to-end approach. Security feedback comes earlier in development (often called “shifting security left”) and teams leverage integrations and automation to continue testing and addressing potential application security challenges throughout the software development lifecycle. While it’s a step up from the traditional approach, end-to-end security testing requires integrations that often break, still returns false positives, and still relies on sending results for developers to fix without collaboration with the security team.

Developer-first approach: Security as part of the developer workflow

Traditional and end-to-end security share the same challenges: Developers and security teams work in silos with multiple tools that slow both teams down. The most effective way to shift security left and succeed against technical debt? Put your developers front and center. Organizations that take a developer-first approach use automated, native security tools like code scanning (SAST) to partner with developers in their preferred environment. Security teams leverage developers’ existing workflows to address security risks earlier, automate vulnerability fixes, and have better security governance to build and protect applications.

Learn more about developer-first security

What can you do with developer-first security?

See how high-performing teams secure their code as they build.

Start building your AppSec stack

Whether you’re ready to dive in or still have questions, we’ve got you covered.