The planned scenario
Supply Chain CI provides the information trail around software delivery. Build status, artifact browsing, package metadata, and webhook intake form the public surface. Private context covers runners, secret references, release approvals, and dependency provenance.
Examine the difference between seeing a build result and being authorized to influence a release. A participant can map the records involved in a pipeline, identify which information belongs with maintainers or approvers, and explain what evidence would substantiate a release integrity claim.
Public surfaces
These reference routes describe possible entry points in the scenario model. They are not live customer services or a guarantee of the routes in a particular product release. Use your configured exercise inventory as the authoritative scope.
| Route | Surface | Context |
|---|---|---|
/ | build-status | Build status dashboard and release overview. |
/artifacts | artifact-browser | Artifact browser and release metadata facade. |
/packages | package-registry | Package registry facade with dependency metadata. |
/webhooks | webhook-intake | Webhook intake and integration event surface. |
Private systems
These service names and segments describe the internal context of Supply Chain CI. They help define exercise boundaries and interpret the generated records.
runner-fleetPrivate runner fleet and job metadata simulation. Catalog segment: private application.
secrets-storeBuild secret reference and rotation workflow data. Catalog segment: private data.
release-approvalsRelease approval and signing workflow representation. Catalog segment: private application.
dependency-cacheDependency cache and provenance data store. Catalog segment: private application.
Configure your exercise
Choose a question for the assignment and define the evidence participants should collect.
- What separates public artifact metadata from private runner, secret, and approval context?
- Which records connect a build, dependency, artifact, and release approval in an investigation?
- Does a visible webhook or package route demonstrate executable behavior, or a represented workflow that needs a supporting observation?
What to hand in
Prepare an artifact and approval evidence map. Record provenance visible in the range, the access boundary under review, and evidence still needed before claiming a compromised release path.
Records and evidence
Pipelines, artifacts, packages, webhooks, runner jobs, and release approvals support software delivery information review. Treat secret records as lab references and do not substitute real credentials or connect the exercise to production build systems.
pipelinesartifactspackageswebhooksrunner-jobsrelease-approvals
Preserve the scenario and product version, the record or observation, and its source with each finding. Distinguish what a participant observed from what the reviewer inferred. Use synthetic data and your defined evidence-retention rules.
Public self-service at launch
Managed Verse is planned for 1 January 2027. Users will create an account, choose a scenario and configure their own authorized exercise boundaries. Vulnverse will host and operate the platform and cloud; users will not need to provision or maintain an exercise cloud.
Managed Verse is planned to replace all previous services. All new inquiries are paused during the transition. Read Managed Verse →.