SBOM Creation Failure Modes

Back in February, I wanted a software bill of materials included with the Intranet Suite release. Generate the SBOM, copy it into the test and production ZIPs, and keep a copy with the other release artifacts.

Why do I want SBOM: because I know IT Security and Compliance will ask for this when I start direct outreaches for Intranet Suite for SharePoint.

This is the six-attempt job I mentioned in the revival post. Most of the trouble was getting the file from one pipeline step to another.

Here’s what broke:

1. The Azure DevOps CopyFiles@2 task copied zero files. The variable in its file-matching pattern hadn’t expanded as expected, and the pipeline carried on.
2. Replacing that task with cp exposed a working-directory problem. The command needed the full path from Build.SourcesDirectory.
3. Passing that full path in one SBOM_PATH variable was still unreliable across steps. The file got its own staging directory, with SBOM_DIR and SBOM_FILENAME passed separately. Each step assembled its own path.
4. The scripts needed stricter error handling and useful logging. Missing files had been too easy to miss in the output.
5. The CycloneDX generator rejected the four-part package version used in that build. Generation needed a temporary change from 0.1.5.2 to 0.1.5+2 in package.json, followed by restoring the original file.
6. That restore only ran if generation succeeded. A cleanup trap made sure a failed run restored the file too.

All that just to get a generated file into three places.

The working pipeline generated the SBOM once in staging, then copied it to each destination with checksums. The separate directory and filename also meant each consuming step could show exactly which file it was trying to copy.