Skip to content

Add SBOM manifest attributes to repackaged Maven wars - #51551

Open
COBI-98 wants to merge 1 commit into
spring-projects:4.0.xfrom
COBI-98:bugfix-sbom-manifest-maven-war
Open

Add SBOM manifest attributes to repackaged Maven wars#51551
COBI-98 wants to merge 1 commit into
spring-projects:4.0.xfrom
COBI-98:bugfix-sbom-manifest-maven-war

Conversation

@COBI-98

@COBI-98 COBI-98 commented Sep 3, 2026

Copy link
Copy Markdown

What's broken

When a project packaged as a war uses cyclonedx-maven-plugin, the SBOM generated at
target/classes/META-INF/sbom/application.cdx.json ends up under
WEB-INF/classes/META-INF/sbom/ once maven-war-plugin packages it.

The repackage goal of spring-boot-maven-plugin never adds the
Sbom-Location and Sbom-Format manifest attributes for this case, even
though the SBOM is present in the resulting executable war.

Root cause

Packager#isCycloneDxBom only recognises SBOM entries at the root-level
META-INF/sbom/ prefix:

private boolean isCycloneDxBom(JarEntry entry) {
    if (!entry.getName().startsWith("META-INF/sbom/")) {
        return false;
    }
    return entry.getName().endsWith(".cdx.json") || entry.getName().endsWith("/bom.json");
}

For a war, the source archive passed to repackage already has the SBOM
under WEB-INF/classes/META-INF/sbom/..., so this check never matches and
addSbomAttributes writes nothing.

This is the same class of problem as #47408 (commit 43cbd9d),
which corrected Sbom-Location for bootWar by adding the
WEB-INF/classes/ prefix. That commit only changed
spring-boot-gradle-plugin, leaving Packager, which is used by the
Maven plugin's repackage and build-image goals, unchanged.

The fix

isCycloneDxBom now also matches META-INF/sbom/ entries beneath the
layout's classes location. This reuses the existing
Layout#getClassesLocation() abstraction ("" for jars and
WEB-INF/classes/ for wars), which Packager#findMainMethod already uses
to locate application classes. The existing root-level META-INF/sbom/
check is kept as-is.

Testing

  • AbstractPackagerTests#sbomManifestEntriesAreWrittenForWar, covering both
    Repackager and ImagePackager since they share the base class.
  • WarIntegrationTests#sbomManifestAttributesAreAddedToRepackagedWar, a new
    Maven integration test project (war-sbom) that runs an actual mvn build
    and asserts on the repackaged war's manifest.
  • Reverted the fix locally and confirmed both new tests fail with the
    attributes missing before restoring it.

Packager#isCycloneDxBom only recognized CycloneDX SBOMs beneath
META-INF/sbom/. In a war, the CycloneDX Maven plugin's output is
packaged beneath WEB-INF/classes/META-INF/sbom/, so repackaging did
not add the SBOM manifest attributes.

Also check beneath Layout#getClassesLocation(), which findMainMethod
already uses to locate application classes. Continue to support the
root location used by jars.

Signed-off-by: COBI-98 <tkdgus968@naver.com>
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Sep 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status: waiting-for-triage An issue we've not yet triaged

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants