Payment Platform

A worked example. Nothing here belongs to you — start your own assessment to see yours.

Coverage: 47%198 of 419 weighted scopes
Effectiveness: 61%
Maturity: 1.0 / 5

NIST SSDF and OWASP SAMM as views over the same controls — nothing here is recomputed.

51% of what was assessed

10 requirements were assessed of 15. The percentage is over those and nothing else.

OWASP · version 2.0

2 satisfied
6 partly covered
2 not satisfied
3 beyond your profile
2 not measured here

Design

2 of 3

Requirement	Status	Controls
TA Threat Assessment	50%	2 of 3 controls counted
SR Security Requirements	0%	1 of 2 controls counted

Implementation

2 of 3

Requirement	Status	Controls
SB Secure Build	75%	2 of 8 controls counted
SD Secure Deployment	33%	3 of 13 controls counted

Verification

2 of 3

Requirement	Status	Controls
RT Requirements-driven Testing	0%	1 of 4 controls counted
ST Security Testing	53%	5 of 11 controls counted

Operations

2 of 3

Requirement	Status	Controls
IM Incident Management	56%	3 of 9 controls counted
EM Environment Management	43%	7 of 16 controls counted

Three answers, not one red bar

Not satisfied — the control is required here and nothing covers it. Yours, and something you can act on.
Beyond your profile — the framework asks for it and your own baseline did not. The framework is stricter than your baseline; no control has failed.
Not measured here — no control in this catalog speaks to the requirement. That is our limit, not your failing, and it is kept out of the percentage.

ST Security Testing

in Verification

Run a scalable automated testing baseline across the whole portfolio, and complement it with deep manual testing by people who understand the application. Streams: Scalable Baseline; Deep Understanding.

Partly covered — 53%. The controls beneath it are covered in some of the places your profile required them and not in others.

No single control answers this requirement outright, so the 5 partial mappings your profile required are averaged.

Closing the 9 scopes listed here would move your overall coverage by 5.5 percentage points — exactly, over the same denominator the headline uses.

Counted toward this requirement

These produced the number above.

SAST Pipeline Scan3 of 3 scopes
Partial mapping · high confidence
What it is
Every build runs static analysis over the application source code and records the result.
Why it matters
Checks in the editor and in review are optional by nature; the pipeline is the one place every change has to pass through.
Why it maps ST-A names automated static analysis as the scalable baseline.
Covered everywhere your profile required it.
SAST Pull Request Gate3 of 3 scopes
Partial mapping · high confidence
What it is
A change carrying a critical static-analysis finding cannot be merged until the finding is fixed or formally excepted.
Why it matters
A scan that only reports leaves the merge decision to the person under time pressure, so critical findings reach the main branch anyway.
Why it maps ST-A at higher maturity: the baseline is embedded in the workflow and acts on results.
Covered everywhere your profile required it.
Automated Dynamic Scan1 of 3 scopes
Partial mapping · high confidence
What it is
The running application is scanned automatically against a deployed test environment as part of the delivery process.
Why it matters
Some faults only exist once the application is assembled and configured: the deployed stack, not the source, is what an attacker meets.
Why it maps ST-A names automated dynamic analysis alongside static as the scalable baseline.
What would close it
The required scopes nothing covers today:
Environment Technology Phase Control point
Development any Test CI Pipeline
Production any Test CI Pipeline
In place looks like Each delivery deploys the application to a test environment and runs the scan against it automatically, with the result recorded per build.
Authenticated Dynamic Scan0 of 3 scopes
Partial mapping · medium confidence
What it is
The dynamic scan runs authenticated so that the functionality behind the login is tested too, not only the public surface.
Why it matters
Almost all of an application's functionality, and most of its authorization logic, sits behind a login that an unauthenticated scan never passes.
Why it maps ST-A expects the baseline to be tuned to the application; scanning behind authentication is where most of an application actually is.
What would close it
The required scopes nothing covers today:
Environment Technology Phase Control point
Development any Test CI Pipeline
Test any Test CI Pipeline
Production any Test
Periodic Penetration Test2 of 6 scopes
Partial mapping · high confidence
What it is
A qualified tester manually attacks the application on a defined cadence and after significant architectural change.
Why it matters
Chained flaws and business-logic abuse need somebody who understands what the application is for; no scanner is looking for them.
Why it maps ST-B deep understanding: expert-led manual testing of what automation cannot reason about. Periodicity alone does not make it risk-driven, as ST-B expects at level 3.
What would close it
The required scopes nothing covers today:
Environment Technology Phase Control point
Development any Test Manual Review
Development any Operate Manual Review
Test any Test

Supporting only, never counted

A control that merely helps cannot be the reason something is called satisfied. Listed so you can see the whole picture, never counted.

SAST Feedback in the IDEnot required
Supporting · medium confidence
Why it maps Moves the same baseline earlier, where the finding costs least to fix.
Insecure Implementation Pattern Detectionnot required
Supporting · medium confidence
Why it maps Extends the automated baseline to organisation-specific insecure patterns.
Dynamic Findings Block the Release0 of 3 scopes
Supporting · medium confidence
Why it maps ST-A at level 3 expects test results to be able to stop a release.
Instrumented Test Runnot required
Supporting · medium confidence
Why it maps Adds runtime observation to the automated baseline without a separate test cycle.
API Security Scan0 of 6 scopes

TA Threat Assessment

50%

2 of 3 controls counted

SR Security Requirements

1 of 2 controls counted

SB Secure Build

75%

2 of 8 controls counted

SD Secure Deployment

33%

3 of 13 controls counted

RT Requirements-driven Testing

1 of 4 controls counted

ST Security Testing

53%

5 of 11 controls counted

IM Incident Management

56%

3 of 9 controls counted

EM Environment Management

43%

7 of 16 controls counted

Environment

Technology

Phase

Control point

Development

any

Test

CI Pipeline

Production

any

Test

CI Pipeline

Environment

Technology

Phase

Control point

Development

any

Test

CI Pipeline

Test

any

Test

CI Pipeline

Production

any

Test

Environment

Technology

Phase

Control point

Development

any

Test

Manual Review

Development

any

Operate

Manual Review

Test

any

Test