Add SBOM manifest attributes to repackaged Maven wars - #51551
Open
COBI-98 wants to merge 1 commit into
Open
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What's broken
When a project packaged as a war uses
cyclonedx-maven-plugin, the SBOM generated attarget/classes/META-INF/sbom/application.cdx.jsonends up underWEB-INF/classes/META-INF/sbom/oncemaven-war-pluginpackages it.The
repackagegoal ofspring-boot-maven-pluginnever adds theSbom-LocationandSbom-Formatmanifest attributes for this case, eventhough the SBOM is present in the resulting executable war.
Root cause
Packager#isCycloneDxBomonly recognises SBOM entries at the root-levelMETA-INF/sbom/prefix:For a war, the source archive passed to
repackagealready has the SBOMunder
WEB-INF/classes/META-INF/sbom/..., so this check never matches andaddSbomAttributeswrites nothing.This is the same class of problem as #47408 (commit 43cbd9d),
which corrected
Sbom-LocationforbootWarby adding theWEB-INF/classes/prefix. That commit only changedspring-boot-gradle-plugin, leavingPackager, which is used by theMaven plugin's
repackageandbuild-imagegoals, unchanged.The fix
isCycloneDxBomnow also matchesMETA-INF/sbom/entries beneath thelayout's classes location. This reuses the existing
Layout#getClassesLocation()abstraction (""for jars andWEB-INF/classes/for wars), whichPackager#findMainMethodalready usesto locate application classes. The existing root-level
META-INF/sbom/check is kept as-is.
Testing
AbstractPackagerTests#sbomManifestEntriesAreWrittenForWar, covering bothRepackagerandImagePackagersince they share the base class.WarIntegrationTests#sbomManifestAttributesAreAddedToRepackagedWar, a newMaven integration test project (
war-sbom) that runs an actualmvnbuildand asserts on the repackaged war's manifest.
attributes missing before restoring it.