Start with Risk, Not a Tool List: Building a Risk-Based SSDLC

Your company has 40 repositories, several production applications, a growing engineering team, and a limited application security budget.

The CTO asks a reasonable question:

“What should we improve first?”

The security team suggests implementing better SAST coverage. Someone else recommends a penetration test. The DevOps team wants to strengthen CI/CD security. An architect argues that the authorization model needs attention.

All four recommendations might be valid.

But which one should receive priority?

Without understanding the applications, their business importance, exposure, and existing security weaknesses, there is no defensible way to answer.

The decision will probably be influenced by whoever makes the strongest argument, whichever vulnerability was discovered most recently, or whichever vendor has the most convincing presentation.

That is not risk-based prioritization.

It is security planning based on incomplete information.

Before deciding which security controls to implement, an organization needs to understand what it is protecting, why it matters, and what could realistically go wrong.

This is one of the most important foundations of a Secure Software Development Lifecycle (SSDLC), and also one of the easiest to overlook.

The problem with starting from tools

Security tools provide visibility into specific technical weaknesses.

SAST can help identify potentially vulnerable code patterns. Software Composition Analysis (SCA) can detect known vulnerabilities in dependencies. Infrastructure scanning can identify misconfigurations. DAST can test certain behaviors of running applications.

These capabilities matter.

But they do not independently tell you which applications deserve the most security attention or where additional engineering effort will provide the greatest benefit.

Consider a fictional multi-tenant SaaS company operating four systems:

A public documentation website.
A customer-facing billing API.
An internal administration console with cross-tenant privileges.
A background service processing customer notifications.

All four may have vulnerabilities. All four need appropriate security controls.

However, their security risks are not equivalent.

A compromised documentation website could be used for malicious content, redirects, or reputational damage.

A broken authorization check in the billing API could expose information across customer boundaries.

An administrative interface might not be publicly accessible, but compromised privileged access could affect every customer organization.

The notification service might have no public endpoint, yet its credentials and integrations could enable data exposure or unauthorized communication.

The right security investments depend on these differences.

If the organization treats all four systems identically, it can spend excessive effort on less consequential risks while underinvesting in business-critical functionality.

The alternative is not to ignore lower-risk applications.

It is to establish a consistent security baseline and then apply additional assurance where the potential impact and credible threats justify it.

That requires application risk classification.

Application risk is not a vulnerability severity score

This distinction is essential.

An application risk profile describes the business and technical consequences associated with an application and the conditions under which security failures could occur.

A vulnerability severity rating describes a particular weakness.

These are related, but different concepts.

For example, a customer identity service may be classified as high-risk because it handles authentication, privileged access, and security-sensitive data across a SaaS platform.

That classification does not mean the service currently contains a known critical vulnerability.

Conversely, a lower-risk public website may contain a remotely exploitable vulnerability that demands immediate remediation.

The organization’s application classification helps determine the appropriate level of ongoing security assurance.

The actual vulnerability risk helps determine how urgently a specific issue needs to be addressed.

Confusing these two concepts produces poor decisions.

A high-risk application does not automatically have an unacceptable residual risk. Strong controls may reduce the likelihood of successful attacks and limit their consequences.

A low-risk application is not automatically safe. It can contain vulnerabilities that create significant exposure, particularly when attackers can use it as an entry point to more important systems.

Application risk profiles guide security investment. Vulnerability risk assessments guide individual remediation decisions. Neither replaces the other.

What OWASP SAMM says about application risk

OWASP SAMM addresses application risk profiling within the Threat Assessment practice under its Design business function.

It describes a progression through three maturity levels.

At the first level, organizations perform basic application risk assessments. A relatively small set of questions can help estimate business impact and the likelihood of relevant attacks.

At the second level, risk evaluation becomes more standardized and the organization maintains a centralized inventory of application risk profiles.

At the third level, the organization regularly reviews those profiles and updates them when applications, technologies, or business circumstances change.

The principle is straightforward: establish a useful understanding of application risk, make it consistent across the portfolio, and keep it current.

SAMM also connects this activity to governance.

Its Strategy & Metrics practice emphasizes understanding organizational risk tolerance, identifying important business and technical threats, and using that information to establish security priorities.

This is an important connection.

Risk classification should not be an isolated exercise performed by the security team.

It should influence engineering decisions, security requirements, verification expectations, and security program investment.

NIST SSDF reinforces this risk-based approach by recommending that organizations align secure development practices with their business requirements, risk tolerance, and available resources.

Neither framework requires a company to begin by purchasing a particular security tool.

Step 1: Know which applications you actually have

Before classifying applications, you need to know what exists.

This sounds obvious, but the software inventory available to a security team is not always suitable for managing application risk.

A repository list tells you where code is stored.

A cloud inventory tells you which infrastructure resources exist.

An SBOM tells you which software components are present in a defined software artifact.

These are useful sources of information, but none necessarily represents the complete application portfolio.

One customer-facing product may contain dozens of repositories, multiple services, several databases, and shared infrastructure.

A single repository may contain components serving multiple products or environments with very different risks.

The useful unit of classification is a clearly defined application, service, or software capability with an understandable business purpose, ownership, and security boundary.

The goal is not to create the most detailed inventory possible.

It is to create an inventory that supports decisions.

For each application or service, a practical starting record should identify its business purpose, accountable owner, relevant repositories and runtime environments, data handled, exposure, critical dependencies, and current risk classification.

Most importantly, the classification needs a justification.

Consider this illustrative inventory:

Application	Exposure	Key business risk	Initial tier
Customer Billing API	Internet-facing	Cross-tenant financial data exposure	High
Tenant Administration Console	Restricted internal access	Privileged changes affecting multiple customers	High
Notification Service	Internal worker	Exposure of contact data or abuse of outbound messaging	Medium
Public Documentation Site	Internet-facing	Content manipulation, phishing, reputational damage	Low

These classifications are examples, not universal answers.

A documentation website with access to privileged deployment credentials could present significantly greater risk than the table suggests.

Similarly, a notification service may become high-risk if it can execute privileged actions or expose large volumes of sensitive customer information.

An inventory must describe actual architecture and dependencies, not assumptions based on application names.

Don’t forget shared services

Shared components deserve special attention.

An identity service, authorization library, CI/CD platform, secrets manager, or shared data-processing service may have a relatively small engineering team but a substantial security impact.

A failure in one of these components can affect multiple applications simultaneously.

If the risk-classification process evaluates only customer-facing applications, it may miss the services with the largest potential blast radius.

This is particularly important in SaaS architectures where identity, authorization, deployment infrastructure, and shared integrations connect otherwise separate services.

Step 2: Define a classification method engineers can actually use

Risk classification does not need to start with complicated mathematical models.

For many engineering organizations, a consistent qualitative approach is sufficient to establish the first meaningful distinctions between applications.

The model should use a small number of well-defined questions.

Here is an example of seven questions that can form the basis of an initial application risk profile.

A practical application risk questionnaire

1. What would happen if the application’s data were exposed, modified, or made unavailable?

Consider confidentiality, integrity, and availability separately.

A reporting service may have limited confidentiality concerns but significant integrity requirements. A customer portal may handle highly sensitive information, while an authentication service may be critical to availability across the platform.

2. What types of data does the application process?

Identify personal data, financial information, credentials, authentication tokens, intellectual property, and other business-sensitive information.

The quantity of data matters, but so does its sensitivity and the impact of unauthorized access.

3. Who can reach the application, and under what conditions?

Consider public interfaces, authenticated customer access, internal users, service-to-service communication, administrative access, and third-party integrations.

An internal application should not automatically be considered low-risk. Its privileges, dependencies, and potential attack paths may make it highly consequential.

4. What privileges and business operations does the application control?

Can it modify payment information, manage user permissions, change tenant settings, access privileged accounts, or perform bulk data operations?

A service able to perform privileged actions may present greater risk than one exposing relatively low-sensitivity information.

5. How many other systems or customers could be affected by a compromise?

Consider shared infrastructure, downstream integrations, customer isolation boundaries, and architectural dependencies.

A small shared component can create widespread consequences.

6. Which contractual, regulatory, or business commitments depend on the application?

Some applications support essential customer operations, contractual commitments, or regulatory obligations.

These factors can increase the consequences of a security failure and influence the assurance expected from engineering.

7. Which credible threats are relevant to this application?

Consider likely attack paths, exposure, attacker incentives, historical weaknesses, and relevant environmental factors.

The objective is not to predict every possible attack.

It is to avoid treating all applications as though they face identical threats.

These questions should be adapted to the organization’s products and risk-management approach.

OWASP SAMM itself suggests using approximately five to ten questions as an initial method for understanding important application characteristics.

The questions are useful only when answers have defined meanings and can be supported by evidence.

Step 3: Turn the answers into meaningful risk tiers

A classification method becomes useful when it produces decisions.

For a relatively small SaaS organization, three tiers may be sufficient:

High: An application where a credible security compromise could cause major business harm, significant customer impact, sensitive data exposure, or compromise of important shared capabilities.

Medium: An application with meaningful security consequences that are more constrained in scope or impact, but still require controls beyond basic hygiene for relevant threats.

Low: An application with limited data sensitivity, privileges, and business impact, where credible compromise scenarios have relatively constrained consequences.

These are illustrative definitions. An organization’s actual thresholds should reflect its risk appetite, business impact analysis, and existing risk-management standards.

Avoid creating a formula in which a few weak indicators mathematically cancel out one severe consequence.

For example, a service with cross-tenant administrative privileges should not become medium-risk merely because it has no direct public endpoint and therefore receives fewer exposure points.

A useful model should explicitly identify conditions that warrant elevated classification or further analysis.

The result should be understandable to an engineering manager without needing a specialist to interpret a proprietary scoring formula.

Avoid false precision

There is a temptation to assign numerical values to every characteristic.

Internet exposure: 3 points. Personal data: 4 points. Authentication: 2 points. External integration: 2 points.

Add the results and calculate a score.

This can create the impression of objectivity without necessarily improving the assessment.

If the weights have no evidence-based justification, the final number is simply a mathematical representation of subjective assumptions.

Quantitative risk analysis can be valuable when a company has suitable data, calibrated estimates, and a methodology aligned with its enterprise risk-management process.

But a small engineering organization does not need to invent an elaborate quantitative model to identify its most sensitive services.

Start with understandable categories, clear decision rules, documented reasoning, and a review process for borderline cases.

Increase sophistication when the decisions justify it.

Step 4: Connect risk tiers to engineering expectations

This is where many risk-classification initiatives lose their value.

The organization creates a spreadsheet, assigns labels, and then continues developing every application exactly as before.

The inventory becomes another security artifact that nobody uses.

A useful classification must influence the Secure SDLC.

For example:

Classification	Illustrative SSDLC expectations
Baseline — all applications	Source protection, peer review, dependency and secret controls, secure configuration, vulnerability handling, and relevant automated testing
Medium risk — additional assurance	Risk-focused security requirements, targeted design review when warranted, additional tests for sensitive functionality, and explicit review of important dependencies
High risk — heightened assurance	Early security involvement for significant changes, threat modeling, explicit verification of critical security properties, stronger release evidence, and risk-appropriate independent assessment

The high-risk tier builds on the baseline. It does not replace it.

The exact assurance activities should be selected according to the application’s threats and architecture.

For example, automated cross-tenant authorization tests are particularly important for a multi-tenant application. They may have little relevance to a completely static public website.

Similarly, a privileged infrastructure automation service may need stronger identity, credential, deployment, and change-control assurance than application-focused dynamic testing.

The goal is not to prescribe every available security activity to every high-risk application.

It is to connect known risk characteristics to controls capable of addressing them.

Risk-based does not mean optional security

A common criticism of risk-based security is that it can become an excuse for skipping controls.

That concern is legitimate.

If teams can declare their applications low-risk to avoid security requirements, the process is not working.

The baseline should establish minimum expectations applicable across the development organization.

Higher classifications should trigger additional assurance, not determine whether basic security practices apply at all.

Classifications also need accountable ownership and an appropriate review mechanism.

The application team should provide the technical context. Security should help evaluate risk and the adequacy of controls. The relevant business or engineering leadership should own decisions that accept material residual risk.

A classification should never be a convenient mechanism for transferring accountability to a spreadsheet.

Step 5: Make risk assessment part of the development workflow

An application risk profile is not something that should be completed once and forgotten.

Software changes.

An internal application may become publicly accessible. A service may begin processing sensitive customer information. A new integration may introduce privileged access. An existing API may become available to external partners.

These changes can alter the application’s risk profile.

That does not mean every pull request needs a new assessment.

Instead, development teams should recognize meaningful risk triggers.

A small change to a non-sensitive user interface might require no reclassification.

But the introduction of a new authentication flow, a new tenant boundary, a privileged integration, or a significant change in the data being processed should trigger an appropriate review.

For example, imagine the notification service from our earlier inventory.

Originally, it only sends messages based on events received from trusted internal services.

Later, the product team introduces an API allowing customers to configure notification destinations and templates.

The service now processes additional untrusted input and may enable new abuse scenarios.

Its original risk classification might no longer accurately reflect its exposure.

The change should prompt the team to reconsider relevant threats, update security requirements, and determine whether additional verification is needed.

This is how risk assessment becomes operational.

A risk profile helps the team make decisions before and during development, rather than existing solely as documentation for an audit.

Step 6: Use risk to build the first SSDLC improvement roadmap

Understanding which applications matter is only the beginning.

The next question is whether the organization’s existing security practices provide sufficient assurance for those applications.

This is where application risk classification and SSDLC maturity assessment work together.

They answer different questions.

Application risk classification: What could happen if this application were compromised, and which threats or conditions make that concern relevant?

SSDLC maturity assessment: How consistently and effectively does the organization perform the security practices needed to manage those risks?

Together, they help identify improvement priorities.

Consider a fictional SaaS company with a high-risk customer billing platform.

Its assessment finds that the organization has reasonable automated dependency scanning and source-code protection, but no consistent process for defining authorization requirements.

Cross-tenant authorization tests are incomplete, and architectural changes are not systematically reviewed.

The company also has an internal documentation portal with several low-severity configuration findings.

Which improvements should receive priority?

Simply counting findings will not answer that question.

The billing platform’s authorization weaknesses may represent a more consequential security gap, even if no scanner currently reports a critical vulnerability.

A reasonable improvement initiative might focus on establishing authorization requirements, reviewing the relevant architecture, and implementing automated negative authorization tests.

The documentation findings still need appropriate handling, but they do not necessarily justify displacing work on the higher-impact risk.

A good SSDLC roadmap connects each improvement to the risk it addresses.

An illustrative first 90 days

For an organization beginning this work, a first roadmap might look like this:

Period	Primary activity	Demonstrable outcome
Days 1–30	Establish application inventory, ownership, and initial risk classification	Reviewed risk profiles for the initial application scope
Days 31–60	Assess existing SSDLC practices and address foundational gaps	Evidence-based gap register and agreed engineering improvement backlog
Days 61–90	Implement and validate selected controls for priority applications	Working security controls, verification evidence, accountable owners, and updated roadmap

This is a sample sequence, not a universal implementation schedule.

An organization with a mature asset inventory may move through classification relatively quickly. A company with fragmented ownership or undocumented legacy systems may need considerably more discovery.

Likewise, an actively exploitable vulnerability cannot be deferred simply because the roadmap currently focuses on governance.

Urgent remediation and longer-term program improvement need to operate together.

The value of a roadmap comes from prioritization, dependencies, and accountable delivery—not from committing to an arbitrary sequence of security activities.

What should a roadmap item actually contain?

A useful improvement item should describe the observed gap, why it matters, what will change, who will deliver it, and how success will be verified.

For example:

Field	Example
Application	Customer Billing API
Risk addressed	Unauthorized cross-tenant invoice access
Observed gap	No consistent negative authorization tests across critical endpoints
Improvement	Define authorization test patterns and implement them for prioritized endpoints
Owner	Billing engineering team
Security support	AppSec reviews test design and coverage
Evidence	Automated cross-tenant tests executing in CI, with failures demonstrated for deliberately unauthorized requests
Completion criterion	Agreed critical flows covered and controls validated

Compare that with a typical security roadmap item such as:

“Improve API security.”

The second statement is an aspiration.

The first describes an engineering change that can be implemented, reviewed, and measured.

This is the level of specificity that makes an SSDLC roadmap useful to engineering leadership.

Risk appetite must come from the business

There is another important distinction between security risk assessment and security decision-making.

The security team can evaluate threats, identify weaknesses, estimate consequences, and recommend appropriate controls.

But it should not independently define which business consequences are acceptable.

Consider a release containing a known security weakness.

Engineering may understand the cost and technical complexity of fixing it. Security may understand the threat and potential impact. Product leadership may understand the consequences of delaying the release.

An informed decision requires those perspectives.

Risk appetite and tolerance provide boundaries for that decision. Specific risk acceptance should follow defined authority, documented reasoning, and any applicable legal or contractual constraints.

Some risks cannot simply be accepted away because a deadline is approaching.

A Secure SDLC should establish who can make these decisions and what evidence is required.

Otherwise, risk acceptance becomes an informal negotiation between the security team and whoever has the strongest delivery pressure.

OWASP SAMM’s Strategy & Metrics practice places considerable emphasis on understanding organizational risk tolerance and aligning the security program with business objectives.

That alignment is not an excuse to weaken security.

It is what makes security investment accountable to the organization.

Don’t turn risk classification into another compliance exercise

A risk inventory can fail in several predictable ways.

The first is classifying everything as high-risk.

This may feel conservative, but if every application receives the same classification, the model loses much of its prioritization value.

The second is using classifications that cannot be explained.

If application owners do not understand why their service is classified as high or medium, the model will not reliably influence engineering decisions.

The third is maintaining the inventory only for audits.

If risk profiles are reviewed annually but ignored when architecture and requirements change, they become increasingly disconnected from reality.

The fourth is confusing classification coverage with risk reduction.

Reporting that 100% of applications have risk ratings may indicate good administrative coverage.

It does not demonstrate that high-risk applications have effective security requirements, appropriate controls, or meaningful verification.

Finally, organizations sometimes spend more effort perfecting the classification methodology than addressing the most obvious security problems.

A risk model should improve decision-making.

If it is too complicated to maintain, too subjective to explain, or disconnected from the development workflow, it needs to be simplified or redesigned.

How to know whether risk-based SSDLC prioritization is working

The objective is not to produce a beautiful heat map.

The objective is to change engineering decisions.

Useful questions include whether business-critical applications have identified owners, whether their risk profiles are current, and whether the organization can demonstrate appropriate security assurance for the risks those applications present.

For example, an engineering leader should be able to select a high-risk service and answer:

Why was this service classified as high-risk? Which security requirements are especially important? What additional review or testing is expected? Where is the evidence that those activities happened? Who owns unresolved security risks?

If answering requires several meetings and substantial investigation, the SSDLC may not yet provide the visibility leadership needs.

A mature process does not necessarily produce more documents.

It makes the important information accessible, reliable, and useful when decisions need to be made.

That is a much stronger indicator of progress than the number of security tools deployed.

Start small, but make it operational

A company does not need to classify every historical script and utility before it can start improving its SSDLC.

Begin with a meaningful scope.

Identify the customer-facing applications, shared security-critical services, privileged administrative components, and systems processing important business data.

Agree on a classification method. Review the initial results with application owners and engineering leadership. Document important assumptions and uncertainties.

Then connect the classifications to actual engineering activities.

What should happen when a high-risk service changes? Which security requirements must be reviewed? What type of verification is expected? Who decides whether identified risks are acceptable?

As the process becomes useful, expand the coverage and improve consistency.

OWASP SAMM provides a structured path for increasing this maturity over time.

The framework is valuable because it helps organizations assess their current practices and define how to improve them.

But the framework itself is not the objective.

The objective is better engineering decisions, stronger security assurance, and more effective investment of limited resources.

The first SSDLC investment should be clarity

There will always be another security tool to evaluate.

A new scanner may improve detection. Better CI/CD controls may reduce supply-chain exposure. More effective security testing may uncover weaknesses that existing tools miss.

These investments can be justified.

But without understanding which applications matter, what threats are relevant, and where existing practices are insufficient, organizations struggle to determine which investment should come first.

That is why risk-based prioritization belongs near the beginning of an SSDLC improvement program.

It establishes a foundation for deciding where security effort will provide the greatest value.

It also helps engineering teams understand why some changes require additional scrutiny while others can proceed through established controls.

Security stops being an arbitrary set of demands and becomes a set of expectations connected to the software’s purpose and potential impact.

A useful SSDLC roadmap does not begin with a shopping list. It begins with an understanding of the software, the business risk, and the decisions that need to improve.

Once those priorities are established, the next challenge is making someone accountable for executing them.

Because even the best security roadmap is ineffective when nobody owns the decisions.

Building a risk-driven Secure SDLC?

Knowing where your security gaps exist is useful. Understanding which ones matter most—and how to address them without unnecessarily disrupting engineering—is what makes an improvement program actionable.

TheOnlySecurity’s SSDLC assessment and consulting services are designed to help organizations evaluate application security maturity, establish risk-based priorities, and translate gaps into practical engineering improvements.

Using OWASP SAMM and NIST SSDF as reference frameworks, the focus is on evidence, realistic maturity targets, accountable implementation, and meaningful security outcomes.

Explore SSDLC Assessment & Consulting →