EN/DE Start free trial
← Back to blog 27 August 2026 · annika-vogt

Tackling the Challenge of Matching Product and Software Release Cycles

Tackling the Challenge of Matching Product and Software Release Cycles

Author: Annika Vogt | Topic: SBOM, Product Security, Supply Chain Risk

1. The Dual-Timeline Problem: Why Hardware and Software Don’t Ship Together

An industrial router leaves the factory with a specific firmware version. Six months later, a critical security update is released for an embedded library. Two years after that, the same device is still running at hundreds of customer sites – with a software base that has changed multiple times, while the hardware has remained untouched.

This scenario is not an exception; it is the normal state of affairs in the embedded, IoT and industrial domain. Hardware release cycles move in months to years: new boards, enclosures or chipsets require extensive certifications, type approvals and supply chain processes. Software, by contrast, follows an entirely different rhythm – patches are released weekly, dependencies update daily, CI/CD pipelines continuously deliver new artefacts.

The consequence: product and software teams work on parallel timelines that rarely run in sync. A medical device that receives a hardware revision every three years can go through dozens of software updates in the same period. Industrial controllers certified to IEC 62443 must document every security-relevant change – regardless of whether the hardware has changed or not.

2. Why This Mismatch Creates SBOM and Compliance Chaos

The real problem does not arise from differing cadences alone, but from the failure of classical SBOM processes to deal with them.

A point-in-time SBOM – that is, a snapshot taken at the moment of a release – is already on its way to becoming outdated the instant it is created. If a software package is updated three weeks after the hardware launch, the SBOM no longer matches the actual state of the delivered product. CVE mappings based on a specific package version no longer fit the new version – or vice versa: a new vulnerability affects an old package version that remains installed in the product, but has long since been replaced by a newer one in the SBOM.

For compliance teams, this means, concretely: evidence for the CRA (Cyber Resilience Act), IEC 62443 or BSI TR 03183-2 drifts apart. An audit document based on the SBOM at the time of CE marking only partially reflects the actual state of the product in the field (see also https://www.eacg.de/en/podcast/s03-fix-is-available/). In the worst case, this leads to liability risks, product recalls or the loss of approvals.

The core problem: SBOMs are treated as static documents, even though they must describe dynamic realities.

3. Core Concepts: What a Product-Level SBOM Actually Needs to Track

Product-centric SBOM management must do more than list packages and versions. It requires several dimensions simultaneously:

  • Versioning across software components: Every software component must be assigned to a specific product configuration with its exact version and timestamp – not in the abstract, but concretely for every delivered hardware revision.
  • CVE mapping at product level: A vulnerability must not merely be assigned to a library, but must be concretely linked to the affected product configuration, the delivery period and the current mitigation status.
  • Lifecycle tracking across hardware revisions: When hardware revision 1.2 is superseded by 1.3, both SBOMs must be maintained in parallel and remain historically traceable.
  • Standards conformity as a continuous state: Standards such as IEC 62443-2-4, the EU Cyber Resilience Act and BSI TR 03183-2 in their current form require not only evidence at the time of placing on the market, but continuous documentation of the security state across the entire product lifecycle.

These requirements cannot be consistently met with traditional tools – spreadsheets, Git snapshots, manually maintained documents.

4. How TrustSource’s Product Package Bridges Both Timelines

TrustSource addresses this problem with a product-centric SBOM approach that treats SBOMs not as one-off artefacts, but as living, versioned objects.

The TrustSource Product Package allows products to be modelled as independent entities to which software components are assigned in specific versions. When a software component is updated, the entire product SBOM is not overwritten; instead, the new software version is assigned to the product while the old version is preserved historically.

CVE mappings are updated automatically and always remain tied to the specific product configuration. When a new vulnerability is reported for a library version installed in product revision 1.2 but not in 1.3, TrustSource shows exactly this differentiation – without manual reconciliation.

The compliance status is not stored as a one-time attestation, but is continuously tracked across both release cycles. Teams can query at any point in time: which CVEs are open for which product configuration? Which mitigations have been documented? Which compliance state applies to which hardware revision?

5. Workflow Walkthrough: From Software Release to Product SBOM Update

A typical workflow with TrustSource looks like this in practice:

  1. Software patch is developed: A new release of a firmware component is built in the CI/CD system. TrustSource automatically generates an updated SBOM for this component.

  2. Product assignment takes place: The new software release is assigned to one or more product configurations. TrustSource updates the respective product SBOM and flags the changed components.

  3. CVE impact analysis is executed: TrustSource automatically checks which known vulnerabilities are fixed or newly introduced by the new release. The results are presented product-specifically.

  4. Differential analysis across product variants: Teams immediately see which product variants benefit from the update and which are still running on the old software version.

  5. PLM integration: Via interfaces to PLM systems, the updated SBOM status can be fed back into existing product lifecycle documentation.

6. Handling CVE Lifecycles Across Frozen Hardware Configurations

The hardest nut to crack in this context: hardware configurations are frozen, but vulnerabilities are not.

A device shipped in 2021 with a specific processor architecture and firmware may be affected by a newly discovered vulnerability in 2025 – without any realistic possibility of changing the hardware. The question is then no longer how to fix the vulnerability, but how to document it, assess it and make the risk acceptance verifiable.

—- In addition, the use of the MITRE EMB3D Framework is recommended as an instrument for structured threat modelling in embedded systems. EMB3D helps identify hardware-specific attack vectors that go beyond classical CVE lists. EACG offers a dedicated training course on this: EACG Academy – EMB3D Course. —-

TrustSource enables precisely this: for every CVE affecting a frozen product configuration, teams can document the risk acceptance process, record mitigation measures (e.g. network segmentation, additional authentication) and keep the handling status verifiable for audits and inquiries from authorities.

This approach corresponds to what the CRA and IEC 62443 require under Vulnerability Disclosure and Post-Market Surveillance: no denial of known risks, but transparent, documented and traceable handling.

7. Getting Started: Practical Steps for Product Security Teams

Anyone looking to introduce this approach should proceed pragmatically:

Step 1: Prioritise existing products. Do not tackle all products at once. Start with those that carry the highest risk level – either due to known CVEs, critical deployment environments or upcoming audits.

Step 2: Define an SBOM taxonomy. Before SBOMs are imported or generated, it must be clear how products, hardware revisions and software releases are structured and named. A consistent taxonomy is the foundation for all subsequent automation.

Step 3: Align development and product teams. SBOM management is not solely a development task. Product managers, compliance officers and security teams must jointly define what information is documented, when and how.

Step 4: Integrate the TrustSource Product Package. With the Product Package, products can be set up quickly, software releases assigned and initial CVE analyses carried out – without months-long implementation projects.

Step 5: Enable CI/CD integration. The greatest efficiency gain comes when SBOM updates are triggered automatically from the build process. TrustSource offers integrations for common CI/CD systems.

Conclusion

The decoupling of hardware and software release cycles is not an unsolvable organisational or coordination problem. It is a structural reality that requires a structural tool.

Three key takeaways:

  • Static SBOMs fail in product environments with differing release cadences. Only a living, versioned product SBOM reliably reflects the actual security state.
  • CVE lifecycle management must be product-specific and not merely component-specific – particularly for frozen hardware configurations where technical fixes are not possible.
  • TrustSource’s Product Package offers a practically viable approach that brings both timelines together, continuously maintains compliance evidence and meets audit requirements under the CRA, IEC 62443 and BSI TR 03183-2.