Starting Strong: Strategies for Developing an Effective Application Security Program

Written By: Seth Kirschner

At DoubleVerify (DV), we built an application security program with the help of several teams and stakeholders within a six-month time frame. With several thousand repositories and hundreds of developers, this was no easy task to accomplish.

Implementing application security requires visibility into your environment, effective communication with stakeholders and an understanding of your most critical assets. This post covers three ideas to consider when establishing an application security program that can help streamline the task. And it offers an example of a tactical approach I took while building this security program.

1. Gain visibility into your environment

As an application developer or security practitioner, it’s critical to know your tech stack in case future critical vulnerabilities are discovered that impact many applications. The term Software Bill of Material (SBOM) has become a trending phrase in the information security community over the past two years. Why? Because of recent increases in supply chain attacks such as Log4Shell, java-based vulnerabilities within a Log4j dependency. This has increased the need for tooling in organizations to help manage your SBOM. It helps to know what open-source tools and code your company has and whether those fall across one or many Source Code Managers (SCMs).

How can you make sure you know your tech stack? First, ensure you have proper tooling and technology in place across your software development lifecycle. This helps you understand what dependencies you’re leveraging in your environment and where to focus your efforts.

Below is a sample list of tools you can use in your environment (non-exhaustive):

• Static Application Security Testing (SAST) Tools: These tools analyze source code and binaries to identify security vulnerabilities without executing the application.
• Dynamic Application Security Testing (DAST) Tools: These test the application while it is running, simulating real-world attacks and identifying vulnerabilities.
• Interactive Application Security Testing (IAST) Tools: These combine SAST and DAST techniques to provide more accurate and actionable results.
• Software Composition Analysis (SCA) Tools: These tools identify vulnerabilities in third-party components, dependencies, and libraries used in an application.

Tools like these can be provided within your SCMs (e.g., GitHub or GitLab). Both offer security testing mechanisms that can be implemented directly into your continuous integration/continuous deployment (CI/CD) pipelines.

As you begin understanding what you have in your environment, it’s even more critical to understand what you should not have. One option to do this is to start compiling a list of technologies that should not be used. This list can be based on recent threats in the industry as well as best practices for managing dependencies. These can be stored in an application security policy or a secure software development lifecycle policy.

When communicating the policy to stakeholders, you can identify teams or applications that may require prioritization for initial remediation efforts.

2. Establish communication channels

To start establishing communication channels, map out a “Technology Landscape Overview” (TLO). This will help identify critical people and technology in your organization.

After interviewing several engineering stakeholders, I mapped out the information below in a concise document:

Team Name

• Relevant sub-team(s)

Technology Stack (per team)

• Coding Languages
• Front end
• Middleware
• Backend
• Authentication / Authorization
• Deployment Tool(s) & CI/CD — if relevant or different

Engineering Lead

• Engineering Sub-lead(s), and it’s important to identify specific individuals

The following information may also be helpful to you:

• Infrastructure Lead(s)
• DevOps Team Member(s)
• Product Lead(s)
• Security Champion(s)
• Type of Data or Infrastructure

Depending on your industry, you may want to include other columns in your spreadsheet (e.g., what teams or applications contain personally identifiable information (PII), personal health information (PHI) or other sensitive/confidential data). Other requirements may include payment card industry (PCI) data or HIPAA, which will help you (and others) as you design your program.

Now, you will have a good idea of who and what is important to focus on. Next, you can establish communication channels throughout your organization.

Whether your organization uses Slack, Microsoft Teams or another communication channel, establish a way to consistently communicate with the stakeholders identified in the above activity without disrupting their day-to-day operations or business as usual.

Below is a sample strategy you can leverage for communication channels:

• Create a general channel open to everyone at your company to join. This may be used primarily by your engineering team(s) or organization, but it is worth having for others if there are any questions.
• Identify critical teams or applications (depending on your organizational structure, one option or both options may be important). Build a channel with each of them privately. Yes, some stakeholders may be in multiple channels (and that’s okay).
• After you create these channels, communicate them to the business in case others want to be part of the program.

Building a standard cadence of communication with the stakeholders will be critical to the success of your program. Two options are to host either a monthly application security forum or team-based monthly touchpoints, which are extremely helpful when kicking off your program.

Every month, for example, you could discuss the following:

• What you achieved in the last 30 days
• What you are working on now
• What you hope to achieve in the next 30 days

As a base, start with all the stakeholders you identified in your TLO document. This most likely will include the major stakeholders and decision-makers in the organization.

Simultaneously, establish an email address for other stakeholders’ concerns. Use this to communicate your information to your company and build awareness for your program.

3. Understand business context

The business context will help you establish a risk-based approach for your application security program. For example, you may want to focus first on your external environment.

This is an excellent opportunity to onboard your business counterparts and update your TLO documentation to include an “externally exposed” tag, check or flag. This may include login pages for customer-facing applications or API services exposed to the internet.

Once you know what is exposed, you can begin identifying users of the application and the criticality of data the application stores and serves.

For example, if your application provides PCI, PII or HIPAA, focus on the applications that are both external and contain sensitive information.

Another option is understanding your application’s users. Are the users customers? Clients? Partners? Building the user profile will help you understand who may impact your business if something happens to the application. If the application is compromised for some reason or goes offline, what would cause the most revenue impact on your organization?

This information can also be captured on the TLO document or within a secondary document to help understand how the business operates and who could be impacted.

Today, several application security posture management (ASPM) tools in the market can help you build out business context and easily manage your applications.

A tactical implementation using tooling at DV

Gaining visibility is one of the first steps required to establish a successful application security program. DV initially chose a tool that could integrate with several different source code managers out of the box. This allowed for quick integration primarily using webhooks to scan our repositories for both SAST and SCA findings.

Within hours of implementing our first tool, DV had visibility into thousands of repositories without disrupting the team’s day-to-day operations.. The tool allowed us to share issues quickly and generate reports easily by copying URLs and passing them to the appropriate parties. With this capability, the application security organization is now able to communicate findings to teams based on the communication channels established above using TLO information. Critical issues were tracked using an out of the box integration with DV’s ticketing system.

We scanned leveraging a team-based approach and then disseminated reports as well to the developer team leads. Furthermore, you can provide additional business context within the application by using tags, allowing you to curate the existing repository data for your organization.

Upon integration with your Single Sign On (SSO) provider and role/group-based access control, you can delegate access to the findings based on their team or application grouping.. This will allow users to focus their time on the platform on the issues that matter the most to them.

As we began to scale, we recognized that the first tool helped mature our program from zero to one, but lacked some requirements allowing us to scale further. At this time DV uses a combination of tooling to ensure coverage and capabilities.

4. Next steps

Establishing an effective application security program is crucial for any organization, but it does not have to be overwhelming. By following key ideas such as gaining visibility into your environment, communicating effectively with stakeholders and understanding critical assets, you can successfully implement a program to protect your organization from potential security threats.

This post only touches on a few aspects of an application security program, but a holistic program has additional components that can offer considerable benefits to your organization. These may involve creating a procedural document, outlining a process flow diagram, setting a timeline for program implementation and providing onboarding training or resources to new hires.

After building out successful application security programs, these ideas have proven helpful to leverage within 90 days of establishing your program. It is important to remember that the application security space is still evolving at a rapid pace, and DV is still relentlessly evaluating ways to best product our environments from code to production.

If you have any questions, please reach out to me directly through LinkedIn or by email at Seth.Kirschner@doubleverify.com.