What is the maturity level of your AppSec program?

Apr 06, 2022 / 4 min read

Table of Contents

Six stages to secure what you sell
Application security at every level

Any organization that wants to secure its software should make maturity of its AppSec program its holy grail. Maturity means making security the first thought, not an afterthought. It means embedding security into software throughout the development life cycle, not trying to patch it at the last minute before production.

Because getting the desired results—building trust into software—doesn’t happen by accident. As a recent analysis by Forrester Research put it in a white paper titled “Gauge the Maturity of Your Product Security Program,” maturity requires more than simply embedding security tooling or deploying application protections.

To get to a maturity level where product security is a business enabler, “security teams must prioritize collaboration with product teams and invest in capabilities that automate security detection and remediation, seamlessly integrate into the product life cycle, and measure the impact on the business and customers,” according to the Forrester white paper.

How can you evaluate your level of maturity? Forrester is ready with a checklist of six stages in what it calls the Forrester Secure What You Sell Model. Those stages are discover, define, align, build, launch, and grow. Within each stage is a list of markers that help an organization determine its current level of maturity and what it may need to do to reach a higher level. In essence, it lets users create their own report card.

Six stages to secure what you sell

Discover: A project in this early stage might be just a gleam in the eyes of the product team, but this is the time to conduct risk assessments, threat intelligence assessments, and possible abuse scenarios. Those can address security and privacy implications the product team may not have considered. It’s the beginning of the maturity activity called “planning ahead.”

Define: To design security into a product, security teams need to know its range of intended uses, who is going to be using it (target markets), and any regulatory requirements. It should also include requirements on upgrading, maintenance, and support throughout the product’s lifetime. The security team can then collaborate with the product team to design what Forrester calls “the thresholds of minimum viable security—the minimum controls necessary to protect the business when the product deploys.”

Align: This means setting staffing, tooling, and licensing requirements to protect the product once customers are using it. It may require new or custom-built tooling if the product will employ new technologies or development approaches. If the product uses open source or third-party software components (as almost all do), it’s important to determine how to manage that third-party risk. That includes creating an inventory, or software Bill of Materials, for all third-party supply chain dependencies including data, code, and materials.

Build: For those with expertise and experience in DevSecOps, the activities at this stage will be familiar. They include automated testing tools like static application security testing (SAST), dynamic application security testing (DAST), and software composition analysis (SCA) integrated into the CI/CD pipeline. This will help developers address security issues throughout the process—instead of “shifting left,” the goal is to “shift everywhere” so that the right test is done at the right time. During penetration testing, security pros should consider misuse scenarios and test the product not just for what it should do, but also what it shouldn’t be able to do.

Launch: At this stage the product is generally available, so the security team must protect it with tools like web application firewalls, bot management, runtime application self-protection, and tamper proofing. These should be designed to protect both the product and customer data based on the risks and threats identified earlier in the life cycle. The team should also collect telemetry to help detect and respond to attacks.

Grow: The job of the security team at this final stage is to analyze feedback from protection technologies and compare the product’s security metrics with established baselines and benchmarks. A key goal is to make product security a competitive differentiator. That means analyzing the customer experience to make any changes that will improve the balance of security and usability.

Application security at every level

If you’re just getting started, don’t expect maturity to happen overnight. It’s going to take investments of time and in people. An organization’s leaders shouldn’t give up if they can’t check all these boxes immediately because, as the cliché says, security isn’t an event. It’s a journey—a process. To help organizations evaluate where they are on that journey and what they need to do, Forrester concludes with some advice on what to do if you’re at the beginner, intermediate, or advanced level.

Beginner: Laying the foundation for product security requires updating security processes and tooling to remove undue friction for developers. Additionally, an assessment of the budget, skills, and tools you have will enable your security team to engage effectively with product teams at all stages of the product life cycle.

Intermediate: The focus at this level should be on investments in automation and metrics. Select automated and integrated tools carefully and introduce them gradually. Then use metrics to measure their effectiveness. And make sure your product security initiatives extend across the entire product life cycle for both new and updated products.

Advanced: At this point, your organization can turn product security features into revenue growth. But those features won’t yield a competitive advantage if nobody knows about them, so this is the time to engage with other business leaders to craft a strategy for creating awareness in the market.