Skip to content
RockPointCyber
← Supply Chain Modernization

Worked example · enterprise

Two suppliers feed production. Neither was chosen, and neither can be verified.

A six-month transformation for an estate with more than one source control platform, a regulated change process nobody will shorten, and delivery velocity on a board report. Strip the product names away and the mandate is simple: put a control at each point where code the organization did not write enters the estate, prove it works, then make it structural.

26
weeks, fixed
4
work streams
6
phases
63
scheduled tasks
7
milestones
10
delivery risks tracked
Read this first

An operating hypothesis, not a delivered engagement

A preliminary operating hypothesis built from a role description and public product documentation, not a proposal and not a delivered engagement. The organization is recorded in the knowledge graph as a modeled prospect, so every baseline, team size and count below is what a program of this shape assumes before discovery. Phase one exists to replace them, and the plan is built so that replacing them changes the numbers without changing the structure.

What discovery changes: the sequencing of the migration waves, the enforcement dates, the policy thresholds, and whether existing tools are integrated with or replaced. What it does not change: the two choke points, the progressive enforcement model, the separation of build and deployment identity, and the requirement that every control leaves evidence.

01 · The argument

Deploying two tools is procurement. Changing where trust is established is adoption.

Procurement takes weeks. Adoption is what six months is actually for, and it is the part that fails. Every control below lands on a team that can decline it, work around it, or comply grudgingly and badly.

Where the controls go

Two suppliers feed almost everything that runs in production. Neither was chosen, neither is governed, and neither can currently be verified. Every control below is placed on the supply rather than on the findings it generates — which is why the backlog shrinks instead of being triaged faster.

01Untrusted supply

Public package registries

Choke point — Dependencies entering the SDLC

The controls in place match versions against published advisories, which makes the entire category of malicious-rather-than-vulnerable packages invisible. A compromised maintainer account, a typosquat, a post-install script running with a developer's credentials — none of these produce a CVE to match against.

  1. 1Curated proxy with a cooldown on new versions

  2. 2Behavioral analysis at the pull request and at install

  3. 3Reachability used to rank what is worth fixing

  4. 4Blocking only where a fix exists and the code can reach it

02Untrusted supply

Public image registries

Choke point — Base images entering production

Container findings dominate the backlog and almost all of them sit in operating system components the application never invokes, shipped because a general-purpose distribution was used as a base. An image that was clean at build accumulates findings within weeks, so even a successful remediation push is a snapshot.

  1. 1Hardened minimal base catalog as the approved foundation

  2. 2Automated Dockerfile migration to carry the waves

  3. 3Continuous rebuild so freshness is maintained rather than achieved

  4. 4Digest pinning, with development variants prohibited in production

Both paths converge

  • Hardened build

    Three separate identities, federated rather than keyed

  • Evidence bound to the digest

    Signature, SBOM and provenance

  • Admission verification

    Checks provenance contents, not just a signature

Admission is the only gate whose failure is a production outage rather than a failed build, which is why it is the last thing switched on rather than the first thing demonstrated.

02 · The work

Three work streams, and the one that has to come first.

A contract role carries no line authority, so work stream zero is the operating model: who owns which control after the engagement ends, and what each department is being asked to commit. It appears in the schedule and the effort totals because it is real work, not preamble. Technical work that outruns that agreement gets reverted.

Stream 011 tasks · 87 effort days

People, culture and the operating model

Neither — this is the precondition for both

Establish who decides what blocks, who operates the thing that blocks and who fixes what is blocked, for every control, before any of them ship.

From

Security is a central team's responsibility. Gates are announced rather than negotiated, and the exception path is informal.

To

Every control has a named decider, operator and remediator. A funded champion exists in each application team, and the exception process runs on a published turnaround.

Success is The first enforcement transition produces exception requests rather than escalations.

Stream 119 tasks · 140 effort days

Dependency and software composition governance

Open-source dependencies flowing into the SDLC

Make every dependency arrive through one governed path, be judged on what it does rather than only on what it is known to be vulnerable to, and be refused before execution rather than reported after it.

From

Direct public registry access, advisory-feed scanning in some pipelines, no install-time control, SBOMs generated inconsistently and never queried.

To

All ecosystems resolve through a curated proxy with a cooldown; malicious packages are refused at install; a rehearsed query answers exposure in minutes.

Success is A newly disclosed compromised package cannot be installed, and “are we affected” is answered from the inventory in minutes rather than days.

Stream 215 tasks · 120 effort days

Container hardening and image governance

Container base images flowing into production

Replace the base image supplier so the vulnerabilities disappear rather than being prioritized, automate the migration so the program is not limited by how many teams can find a sprint, and enforce the result so the estate does not drift back.

From

General-purpose base images pinned by mutable tag, a large backlog, remediation by patching, no freshness measure and no admission control on provenance.

To

Majority of production services on hardened minimal images pinned by digest, migration automated and repeatable, freshness tracked, runtime baseline enforced.

Success is Median known vulnerabilities per production image falls by an order of magnitude and stays there without a standing remediation effort.

Stream 318 tasks · 154 effort days

Pipeline enforcement, identity and artifact integrity

The pipeline that joins both — and the last gate before production

Turn the pipeline from an automated engine that will do whatever the repository tells it into a verifiable chain of custody, where every artifact carries evidence bound to its digest and nothing without that evidence can run.

From

Mutable action references, broadly scoped tokens, persistent runners, one identity across build and deploy, no signing and no admission verification.

To

Actions pinned by commit, read-only default tokens, ephemeral runners, three separated identities, keyless signing with digest-bound evidence, and admission verifying provenance contents.

Success is A deliberately substituted or unsigned artifact is refused at admission, and every chain-of-custody question from week two is answerable from the pipeline's own evidence.

03 · How it gets switched on

Progressive, dated, and reversible — in that order.

The enforcement ladder, with dates and a way back

Nothing goes from off to blocking. Every control climbs six rungs with published dates, measured exit criteria and a rollback trigger at each one. It is slower per rung and considerably faster overall, because nothing has to be walked back.

  1. 1Observe3 weeks

    Blocks

    Nothing

    The developer sees

    None. Developers are not aware the control is running.

    Goes back down if

    Data collection is failing or the sample is unrepresentative.

  2. 2Advise3 weeks

    Blocks

    Nothing

    The developer sees

    A comment on the pull request explaining what was found and why.

    Goes back down if

    Finding text is unclear enough that champions cannot explain it.

  3. 3Warn4 weeks

    Blocks

    Nothing, but the check is visibly red

    The developer sees

    A red check, a link to guidance, and the date it starts blocking.

    Goes back down if

    Warning volume is flat or rising after four weeks, which means the remediation path does not work.

  4. 4Block critical6 weeks

    Blocks

    Known malicious packages, actively exploited vulnerabilities with a fix, unsigned artifacts, mutable tags in production

    The developer sees

    A blocked merge with the specific reason, the fix, and a one-click exception request.

    Goes back down if

    A blocked release causes a production or regulatory incident, or exception volume exceeds the process's capacity.

  5. 5Full enforcement4 weeks

    Blocks

    Everything above, plus reachable criticals with a fix, unapproved base images, unpinned third-party actions, any artifact without signature, SBOM and provenance

    The developer sees

    Predictable. The rules have been visible for months and the fix path is in the paved road.

    Goes back down if

    Sustained delivery degradation attributable to the gate.

  6. 6Governed exceptionssteady state

    Blocks

    Everything at full enforcement, minus live, approved, time-bound exceptions

    The developer sees

    A documented route to ship under a deadline, with a date by which the underlying problem must be fixed.

    Goes back down if

    Exceptions being renewed indefinitely, which means the remediation path is broken.

The rung most programs skip is Warn. A non-required check that goes visibly red without blocking the merge creates real pressure without creating an outage, and it finds the teams who will need help before they are blocked rather than after. Jumping from Advise to Block is the single most common reason a gate is rolled back permanently — and a gate disabled during an incident spends the credibility of the next one too.

04 · What it leaves behind

Evidence produced by the pipeline, not assembled before an assessment.

Evidence at every point, and the question it answers

Audit evidence is produced continuously by the pipeline rather than assembled before each assessment. Every control leaves something readable; the test of whether it was worth leaving is the third column.

  1. 01Dependency intake

    Control

    Curated proxy with cooldown and malware scanning

    Leaves behind

    Resolution log, per ecosystem, naming the version and the source

    Answers

    “Where did this package come from, and how long had it existed when we took it?”

  2. 02Pull request

    Control

    Behavioral analysis of the dependency change

    Leaves behind

    The review comment and its verdict, attached to the commit

    Answers

    “Who approved this dependency, knowing what?”

  3. 03Build

    Control

    Ephemeral runner, scoped egress, SHA-pinned actions

    Leaves behind

    Build log and the runner's network policy as applied

    Answers

    “What could this build reach, and what did it?”

  4. 04Release

    Control

    Keyless signing with SBOM and provenance bound to the digest

    Leaves behind

    Signature, SBOM and provenance attestation, plus a transparency log entry

    Answers

    “What is in this artifact, and which workflow built it from which commit?”

  5. 05Admission

    Control

    Policy verifying provenance contents, not just a signature

    Leaves behind

    The admission decision, with the policy version that made it

    Answers

    “Why was this allowed to run, and what would have been refused?”

  6. 06Operate

    Control

    Inventory queryable by component

    Leaves behind

    A dated query result naming every affected workload

    Answers

    “Are we affected, and which workloads, right now?”

05 · How it gets measured

Every metric defined before collection starts.

A metric whose definition changes mid-program cannot show a trend, and changing one after an unflattering result destroys the credibility of every other number on the page.

Headline metrics: assumed baseline against the six-month target

Each pair is scaled to its own larger value, because these metrics share neither a unit nor a direction. Baselines are planning assumptions until phase one replaces them with measurements — which is the first thing the engagement does.

  • Admission verification coverage

    higher is better · by week 26

    Baseline0%
    Target95%

    Production namespaces enforcing signature and provenance verification.

  • Artifact provenance coverage

    higher is better · by week 24

    Baseline0%
    Target90%

    Production artifacts with signature, SBOM and provenance bound to the digest.

  • Minimal base image adoption

    higher is better · by week 24

    Baseline4%
    Target80%

    Production services on an approved hardened base image.

  • Median known vulnerabilities per production image

    lower is better · by week 24

    Baseline142
    Target5

    Known vulnerabilities in a median production image, with the host layer included in the denominator.

  • Mean time to detect a malicious package

    lower is better · by week 18

    Baseline2d
    Target15m

    Minutes from publication of a malicious package version to it being blocked.

  • Time to determine exposure

    lower is better · by week 24

    Baseline2d
    Target30m

    Minutes to name every running workload containing a newly disclosed component, measured in a drill.

The guardrails

Reported in the same view as the security improvement, on purpose. A program that buys security with velocity nobody measured is a program that gets reversed.

Security build time overhead
0m → 4m by week 20
Developer-reported false positive rate
0.60 → 0.15 by week 20

Outcome, control, guardrail

Outcome indicators say whether risk fell. Control indicators say whether the control is operating. A program reporting only the first will eventually report a good number produced by a gate that has been silently failing open.

  • OutcomeMedian known vulnerabilities per production image

    Catches: Nothing — this is the result.

  • OutcomeTime to determine exposure

    Catches: An SBOM archive nobody can query.

  • ControlAdmission verification coverage

    Catches: Namespaces quietly exempted.

  • ControlProvenance coverage

    Catches: Enforcement that would fail if it were actually enforced.

  • ControlException renewal rate

    Catches: Permanent exceptions disguised as temporary ones.

  • GuardrailDeployment lead time and build overhead

    Catches: Security improvement bought with velocity nobody measured.

06 · What gets demonstrated, and when

Seven points where somebody watches it work.

Seven milestones, each a demonstration

Every one of these is something you can watch happen. A milestone that can be met by producing a document is a milestone that will be.

  1. W4

    Baseline established and mandate secured

    Present the measured current state and a completed chain-of-custody record for two real production services, with every unanswerable question marked and assigned.

    At risk if Access to registries, clusters or audit logs is delayed beyond week two.

  2. W9

    Paved road live and policy published

    A new service scaffolded from the shared template passes every gate the program intends to enforce, with no security involvement and no changes.

    At risk if Platform engineering capacity is best-effort rather than named and allocated.

  3. W14

    End-to-end pilot proven and costed

    Demonstrate a deliberately unsigned image refused at admission, then the same image signed and admitted, and present the measured effort per service for the whole chain.

    At risk if The pilot cohort is chosen for willingness rather than representativeness.

  4. W18in engagement

    First blocking gates live without delivery impact

    Report that the narrowest defensible blocking set is enforcing across the estate and that the delivery guardrail metrics are within tolerance of baseline.

    At risk if The exception process has not been exercised with real requests before the first block.

  5. W22in engagement

    Majority of the estate on hardened images

    Present the month-over-month reduction in median known vulnerabilities per production image, by wave, with the host layer included in the denominator.

    At risk if Migration automation is not in place before the scale phase.

  6. W26in engagement

    Admission verification enforcing in production

    Repeat the week-two chain-of-custody exercise on the same services and show every question answerable from the pipeline's own evidence.

    At risk if Provenance coverage is below threshold, or Cloud Operations has had under four weeks notice.

  7. W26in engagement

    Handover complete and roadmap owned

    Demonstrate a client platform engineer changing a policy threshold, testing it and rolling it out, unaided.

    At risk if Pairing did not start in week four and handover is attempted as a documentation exercise.

07 · The tools, and what each one does not do

Naming a product is not a design.

What makes a tool choice defensible is knowing its boundary — the thing a reader will assume it covers, and that it does not. We resell none of these, which is why the boundaries are printed rather than discovered during the rollout.

  • Socket

    Behavioral analysis of dependency changes at review and install time, with reachability used to rank what is worth fixing.

    Boundary It is not a CVE database. It answers whether a package just started doing something new, which is what catches a compromise before an advisory exists — and it complements rather than replaces vulnerability lifecycle management.

  • Chainguard Containers

    Minimal, daily-rebuilt base images as the approved foundation, removing packages rather than waiting for patches to them.

    Boundary It cannot fix vulnerabilities inside the application's own shipped dependencies. A base image change reaches the operating system layer; a finding in a bundled library closes when that vendor ships a release.

  • Sigstore Cosign

    Signing image digests and attaching SBOM and provenance attestations, without a key to store.

    Boundary Signing without verification changes nothing. The value is created at the verifier, and only if the verifier constrains identity and provenance content.

  • Fulcio and Rekor

    The certificate authority that binds a short-lived certificate to a verified workload identity, and the transparency log that makes the signing event auditable afterwards.

    Boundary The certificate proves who signed; which issuers and subjects are acceptable is a policy decision that must be made explicitly or the check accepts anyone. A log entry proves something was signed at a time — it says nothing about whether the thing signed was built from the right source.

  • Kyverno

    Kubernetes-native admission policy: signature and attestation verification plus the workload security baseline.

    Boundary Policy schema and verification fields move between versions, so policies are version-pinned and tested in audit mode. An engine already deployed should be used instead of adding a second.

  • SLSA

    The framework defining what provenance must assert and what a consumer must verify.

    Boundary A maturity model, not a certification. Provenance generated by the same job that builds is self-asserted, and claiming a build level above that needs a builder the release job does not control.

08 · Why we can produce this at all

The plan is a query, not a document.

Every table and figure on this page is the result of a named query against Gantry, our knowledge graph of controls, capabilities, products, frameworks and the attack techniques they close. The source brief publishes each one so it can be re-run.

That is the difference that matters commercially. Change an assumption — a different registry, a different compliance obligation, half the repository count — and the plan changes. It does not get rewritten, and it does not get rewritten by someone billing you for the week it takes.

Most consultancies start an engagement at zero and spend the first month building a model of your estate. We start with the model and spend the first month replacing its assumptions with your measurements.

The tools this runs on

The queries behind this page

  • ENG.01The engagement at a glance: mission, outcomes, shape and scale
  • ENG.02The work streams and the choke point each one closes
  • ENG.03The timeline: phases, weeks, posture and what each proves
  • ENG.08The enforcement ladder, and the week each policy reaches each rung
  • ENG.09Enforcement by week — what changes for developers, and when
  • ENG.12Deliverables register — what gets produced, and who owns it after
  • ENG.14Headline metrics: baseline, target, and which task moves them
  • ENG.22Which framework requirements the plan satisfies, and the task that does it
  • ENG.24Attack techniques and risks the plan closes, and where
  • ENG.28Critical path — tasks with dependants, ordered by how much rides on them
  • ENG.30The signing chain — every stage that must hold for a deploy to be trusted
  • PIPE.02Full pipeline view: stages, gates, capabilities, products and frameworks

The rest of the plan

The structure is public. The schedule is yours.

The full plan adds the week-by-week schedule for all 63 tasks, the operating model by department, the deliverables register with named owners, the compliance crosswalk, the enablement program, and the reference implementations — the pull request gate, the hardened Dockerfile, the release job, the admission policy and the VEX statement, as working code.

None of that is useful as a sample, because all of it is specific to an estate: which registry, which identity provider, which gate order, which exceptions get an owner and an expiry.

Book a scoping callHow the engagement runs

The other worked example

This one is a hypothesis at enterprise scale. The other is measured, on us.

We ran the same method on our own monorepo and published the numbers: 236 findings to 8 on the same database version, 202 of which had no fix available upstream. One codebase, one container, nothing assumed.

Read the measured rollout plan