Not a sidecar process — the configuration-management data model that caps the maturity of every other process area. Outcomes, work products, and how they map to your tools.
ASPICE SUP.8 Configuration Management establishes and maintains the integrity of all work products — identifying configuration items, controlling their versions and modifications, freezing baselines, and reporting status. It is the enabling layer: every other process area is a set of configuration items and links, so no process reaches CL2 beyond the maturity of the CM data model underneath it.
If you fix one process first, fix this one. SUP.8 is where the configuration-management data model lives — and that model is the basis that only allows mature processes across every other group.
Purpose (per the ASPICE PAM): establish and maintain the integrity of all work products of a process or project and make them available to affected parties.
The process is achieved when these outcomes hold:
Define what is under CM, the branching/baseline scheme, tools, and responsibilities.
Give every controlled work product a unique identity and characteristics per the strategy.
A system that stores items, versions, and links with controlled access.
Freeze internally consistent sets of items at defined points (e.g. per release/milestone).
Changes to items and releases go through defined control (ties to SUP.10).
Record and report the status of items, baselines, and change requests.
Check completeness and consistency of the baselines and items.
The output work products SUP.8 asks for (named per the standard):
This is where the standard meets reality. Each work product and outcome has a concrete home — an issue type, work-item type, or model element — in the tools you already run. Types are configurable, so treat this as the typical ASPICE setup:
| Work product / outcome | Jira | Polarion | Codebeamer | DOORS Next | Enterprise Architect | Confluence |
|---|---|---|---|---|---|---|
| WP: Configuration management plan / strategy | project scheme + workflow config (documented) | CM plan document / LiveDoc | CM plan document item | CM plan module | — | CM plan page (branching/baseline scheme) |
| WP: Configuration item list | saved JQL filter defining the controlled set | Work Item query / Collection | tracker view / saved query | module object set | model browser index | CI-list page |
| Outcome: item identity + version control | issue key + full change history | each Work Item versioned (revisions) | each tracker item versioned | each Object version-controlled | each element under version control | each page versioned |
| WP / outcome: baseline | Version / fix-version release snapshot | Baseline (revision snapshot of a space) | Baseline | Baseline of a module / component | Baseline of a package | page-version / space snapshot |
| Outcome: branch / variant control | release branches / components (weak) | branched baselines | branching | module variants | version-controlled packages | — |
| Outcome: bidirectional traceability (suspect-aware) | issue links + suspect (R4J / RTM) | Linked Work Items + suspect flag | trace links + suspect | link modules | «trace» relationships | — |
| WP: configuration status accounting | JQL dashboards / reports | LiveReports | reports / dashboards | attributes + views | model reports | status-accounting page |
| WP: backup / recovery & archive records | instance backup / admin records | repository backup records | backup records | database backup records | model archive | backup/DR page |
The trap isn't the tools — it's that the links between them are maintained by hand and decay the moment a requirement changes. (See best ASPICE tools.)
Here is the part almost everyone misses. SUP.8 can never reach a mature capability level (CL2+) on its own — it can only be as mature as the configuration-management data model underneath it. SUP.8 Configuration Management is the secret enabling layer: the shared data model of items, versions, baselines and links that is the basis on which every other process group becomes provable. Scatter that data model across a Jira project, a Polarion space, a DOORS module, an EA model and a Confluence tree, and the model is fragmented by construction — the traceability that SUP.8 depends on decays the moment anything changes, and no amount of process ceremony fixes it.
What actually unlocks maturity is a headless ALM — an API-first, tool-agnostic configuration-management data model that is the single source of truth for every work product and every link, readable and writable by both humans and agents — plus an agent/human workflow definition, coordination and traceability platform on top of it, so every change is planned, assigned (to a human or an agent), executed and traced against that one model. That is the layer that lets SUP.8 be mature instead of theatrical.
The maturity of every ASPICE process is capped by the maturity of the configuration-management data model underneath it. That's the whole game.The enabling-layer thesis
ASPICE deliberately gives you no blueprint. So we wrote one. This SUP.8 guide is part of The Blueprint — our free, open template QMS for ASPICE: every VDA-scope process area, its outcomes and work products, mapped to concrete artifacts in your tools and grounded in one configuration-management data model. Take it, use it, no cost.
Agents can only be trusted when the configuration items and baselines are themselves under control — which is exactly why the CM data model is the first thing to get right, and why it belongs in a headless ALM rather than five hand-synced tools. And we offer to implement The Blueprint for you: our agentic solutions (Vera generates SUP.8's work products and traceability as a byproduct of the build, each with a confidence score and audit trail) running on a partner headless ALM — the API-first configuration-management data model that makes the whole thing provable.
SUP.8 Configuration Management is the process that establishes and maintains the integrity of all work products — identifying configuration items, controlling versions and modifications, establishing baselines, and reporting status. It is the enabling layer the rest of ASPICE depends on.
Because every ASPICE work product is a configuration item with a version and links, and no process can be more mature than the CM data model beneath it. Weak CM caps the capability level of SYS, SWE, SUP and MAN alike.
A configuration management plan/strategy, a configuration item list, baselines, configuration status/status-accounting records, and backup/recovery records.
In Polarion every Work Item is a versioned configuration item and a Baseline freezes a consistent revision; in Jira issues carry keys and history with fix-versions/releases as baselines and issue links (with suspect flags) as traceability. Both need the links kept consistent as items change — which is where a headless ALM helps.
Grounded in the standard, honest about the theater: All VDA-scope process areas · CM data model & headless ALM · SUP.10 Change Requests · SWE.1