Key Considerations for Building an Application Security Program
Updated June 26, 2024.
Implementing and refining an application security program can harden your applications in the cloud and guard against cyber attacks – which are becoming increasingly common targets.
Throughout this article, we’ll cover some of the core technologies and processes that make up modern application security programs, as well as which stakeholders should be involved.
In the spirit of simplicity, this article will focus on three general pillars of an application security program:
1. Product Security Owners translate program objectives into controls and processes.
Application security objectives can include:
Reduce the risk of security breaches: consider performing threat modeling exercises to understand the core risks of your application, and implement security testing technologies that address those risks.
Meet compliance requirements: such as those described in SOC2, PCI-DSS, and HIPAA.
Meet customer requirements: some customers may require specific security controls before making a purchase, such as a Software Bill of Materials (SBOM) to demonstrate supply chain security.
2. Developers independently and consistently resolve vulnerabilities before production.
As we’ll discuss later on, the success of any application security program will ultimately depend on empowering developers to consistently deliver secure code.
Most developers aren’t code security experts and they’re on tight schedules to deliver new features, so the Product Security Owners will need to design processes that provide actionable feedback for developers to resolve security issues, without slowing them down.
3. Security leaders demonstrate coverage and progress to customers and auditors.
Application security programs are only as good as their proof. Security leaders will need to demonstrate the security controls they've implemented, and which resources each control covers. They’ll also need to demonstrate that these controls have had a measurable impact on the security posture of their applications.
The core stakeholders to implement an AppSec Program
Now that we’ve defined the basic pillars of an application security program, let’s dive deeper into each stakeholder involved.
Product Security Owner
The Product Security Owner bears the difficult responsibility of translating larger strategic objectives – such as reducing security risk or gaining compliance with industry standards – into specific security controls and processes.
These “controls and processes” will act as guardrails that enable developers to build systems that align with those strategic objectives. Ideally, the Product Security Owner won’t be involved with vulnerability remediation. Considering the volume of software vulnerabilities in most organizations, they’ll become a bottleneck if developers rely on them to fix issues.
For this reason, their mandate is to equip development teams with tools and processes to independently resolve vulnerabilities on their own. This is aligned with the “shift left” mentality, which asserts that resolving code security issues early in the SDLC is faster than finding them in runtime, which requires security teams to triage each issue back to the relevant developer.
Threat landscapes and compliance requirements are constantly changing, so Product Security owners will need to adjust controls without disrupting developer workflows.
Developers
While the success of an application security program depends on whether developers consistently deliver secure code, they often (and understandably) resist application security tools and processes because they conflict with the primary objective for developers: to deliver innovative features quickly.
Developers resist most tools because they’re forced to leave their environment to scroll through long vulnerability backlogs – which may not be relevant to their current code change. This user experience is slow and burdensome, which can create friction in development cycles.
Consider security tools and processes that provide immediate feedback on the security of every code change, without requiring developers to leave their coding environment. These tools should share the same UX, so that developers don’t need to learn how to use many different technologies.
In the example below, Jit automatically provides feedback on the security of new code and remediation guidance entirely within the developer’s GitHub environment, so they can quickly make the fix and get back to coding.
Development Team Leads
An underrated stakeholder in any application security program are Development Team Leaders. Application security is largely a software development initiative, so Development Team Leaders are going to play a crucial role enforcing the processes needed to deliver secure code.
To help carry out an application security program, Development Team Leaders need full visibility into the security posture of the services their team builds and maintains. With this information, they can highlight gaps and understand which developers need help. Ideally, they’ll have a prioritized list of the top risks in their environment, so they can effectively triage issues without obstructing development progress.
Security Leaders
Security leaders will need to define the business objectives that are carried out by the Product Security Owner and Development Team Leaders. Aside from defining the objectives, Security Leaders will need to prove that they’ve met the requirements of those objectives. This can include metrics and documentation like:
- Which security controls are in place, and which resources they cover
- Unresolved vulnerabilities in production
- A Software Bill of Materials to demonstrate supply chain security
Application security testing tools to consider
Selecting application security tools will be among the most critical decisions to make as you plan your application security program.
| AppSec testing tool | What part of your stack does it scan? | What vulnerabilities can it find? | How is it normally integrated into the SDLC? |
|---|---|---|---|
| Static Application Security Testing (SAST) tools | Custom code written by your developers. | Code injections, insecure functions, authentication weaknesses, and cryptographic weaknesses. The OWASP Top 10 is a good place to start. | SAST can be integrated in the IDE or SCM to automatically scan new code as its committed. |
| Software Composition Analysis (SCA) | Open source code included in your applications. | Known vulnerabilities in open source components and their dependencies. | SCA is often integrated in the SCM or build system to provide feedback on the security of open source components before production. |
| Secrets detection | Any applications that authenticate with secrets. | Hardcoded passwords, API keys, cloud tokens, and other hardcoded secrets. | Like SAST, secrets detection can scan static code in the IDE or SCM to catch hardcoded secrets early. |
| Dynamic Application Security Testing (DAST) | Scans your applications in runtime. While it doesn’t align with a shift-left approach, these tools provide low false positive rates. | DAST finds similar vulnerabilities as SAST, just in runtime instead of earlier in the SDLC. | DAST scan applications at runtime. Most DAST tools can be configured to scan applications on a schedule or after each deployment. |
With these application security tools, you can proactively surface and mitigate vulnerabilities in your code before attackers, but this is just part of the product security picture.
The other component to consider is cloud infrastructure security. Just like developers can push insecure code, they can also misconfigure cloud infrastructure to expose sensitive data – such as leaving an AWS S3 bucket open.
Consider using automated tools to scan your IaC files and your cloud runtime environment for security issues in your infrastructure.
Key questions to consider
Planning
What are the core risks of our applications?
What are customers asking for?
What are the compliance requirements we need to align with?
Tools
Which tools are needed to satisfy specific requirements and/or to reduce the risk of a security incident?
How will these security tools work together to achieve a shared objective?
How will specific controls be integrated and enforced throughout the SDLC?
Process
Who is going to own the configuration, implementation, and maintenance of these controls?
How can we incorporate security tools into developer routines without hampering developer velocity?
How can we stay notified if vulnerabilities enter production?
Who will be held accountable for the results these tools generate?
How will these results be reported and presented in a way that satisfies customers, auditors, and leadership?
How will we know we’re on the right track?
Implementing an Application Security Program with Jit
Jit’s Open ASPM Platform provides an all-in-one platform for application and cloud security, including SAST, SCA, secrets detection, DAST, IaC scanning, CSPM, and other controls.
We’ve carefully considered the requirements of each stakeholder needed to implement an effective application security program, and deliver them the following solutions:
Product Security Owners can implement Security Plans, which bundle the relevant tools and reporting needed to achieve a specific objective, like gaining SOC2 compliance, meeting the OWASP Top 10 guidelines, or implementing full application security coverage. Security Plans can integrate these toolsets across code repositories in minutes, while making it easy to plug in new tools as requirements change.
Developers get immediate feedback on the security of every code change without requiring them to scroll through vulnerability backlogs in separate UIs. They can easily see how their code change impacts the security of their applications, while auto remediating issues with Jit’s code suggestions. Issues are prioritized according to their runtime context, so developers can focus on exploitable issues in production, so they aren’t overwhelmed with false positives. For these reasons, Jit is the easiest way for developers to adopt continuous security into their daily routines.
Development Team Leads get their own portal to monitor the security posture of the services their team builds and maintains. They can also see the top security risks in their services, with the option to create pull requests to remediate the top issues. Each team gets a score based on unresolved vulnerabilities in production, which can be optionally displayed on a leaderboard to provoke friendly competition.
Security Leaders see an overview of their application security posture, along with a breakdown of resource coverage across their environment. This data can be exported to make it easy to share with customers and auditors.
Interested in learning how you can implement an AppSec program with Jit? Check out our platform page to learn more.
