feat(security): add comprehensive SBOM generation and integration

[arunsanna]

Summary

• Added comprehensive Software Bill of Materials (SBOM) generation workflow
• Integrated SBOM generation into existing container and dependency security workflows
• Updated security report to aggregate and analyze SBOM data

Changes

New Workflow: security-sbom.yml

• sbom-source: Generates SBOMs for source code using Syft and cdxgen
• sbom-containers: Creates SBOMs for Docker containers in multiple formats
• sbom-vulnerability-scan: Scans all SBOMs with Grype for vulnerabilities
• sbom-attestation: Creates SBOM attestation for main branch commits
• sbom-publish: Publishes SBOMs as release assets

Updated Workflows

• security-containers.yml: Added Syft SBOM generation alongside container scanning
• security-dependencies.yml: Integrated CycloneDX SBOM generation for npm dependencies
• security-report.yml: Added SBOM analysis section and supply chain tracking

SBOM Formats Supported

• SPDX 2.3 JSON
• CycloneDX 1.5 JSON/XML
• Syft native JSON
• NPM dependency trees
• License compliance tracking

Testing

All workflows include:

• Error handling with continue-on-error: true
• Multiple format generation
• Vulnerability correlation
• Artifact uploads for all SBOMs

Benefits

• Complete software supply chain transparency
• Multi-format SBOM support for different tools
• Automated vulnerability scanning of all components
• License compliance tracking
• Release asset publishing for SBOMs

[Copilot]

Pull Request Overview

This PR adds comprehensive Software Bill of Materials (SBOM) generation and vulnerability scanning capabilities to the security workflow infrastructure. The implementation creates a dedicated SBOM workflow while integrating SBOM generation into existing container and dependency security workflows.

• Implements comprehensive SBOM generation using multiple tools (Syft, cdxgen, CycloneDX) with support for various formats (SPDX, CycloneDX, Syft native)
• Integrates vulnerability scanning of SBOMs using Grype and adds SBOM attestation for supply chain security
• Updates existing security workflows to include SBOM generation and enhances security reporting with supply chain tracking

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
.github/workflows/security-sbom.yml	New comprehensive SBOM workflow with source code, container, and vulnerability scanning jobs
.github/workflows/security-report.yml	Added SBOM analysis section to aggregate and display supply chain information
.github/workflows/security-dependencies.yml	Integrated CycloneDX SBOM generation for npm dependencies
.github/workflows/security-containers.yml	Added Syft SBOM generation alongside existing container scanning

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The variables TOTAL_CRITICAL, TOTAL_HIGH, TOTAL_MEDIUM, and TOTAL_LOW are modified inside a subshell created by the pipe to while read. These changes won't persist outside the loop, so the totals will always remain 0. Use process substitution instead: while read vuln_file; do ... done < <(find . -name \"vuln-*.json\")

Suggested change

	find . -name "vuln-*.json" | while read vuln_file; do
	if [ -f "$vuln_file" ]; then
	CRITICAL=$(jq '[.matches[] | select(.vulnerability.severity == "Critical")] | length' $vuln_file 2>/dev/null || echo "0")
	HIGH=$(jq '[.matches[] | select(.vulnerability.severity == "High")] | length' $vuln_file 2>/dev/null || echo "0")
	MEDIUM=$(jq '[.matches[] | select(.vulnerability.severity == "Medium")] | length' $vuln_file 2>/dev/null || echo "0")
	LOW=$(jq '[.matches[] | select(.vulnerability.severity == "Low")] | length' $vuln_file 2>/dev/null || echo "0")
	TOTAL_CRITICAL=$((TOTAL_CRITICAL + CRITICAL))
	TOTAL_HIGH=$((TOTAL_HIGH + HIGH))
	TOTAL_MEDIUM=$((TOTAL_MEDIUM + MEDIUM))
	TOTAL_LOW=$((TOTAL_LOW + LOW))
	fi
	done
	done < <(find . -name "vuln-*.json")

[Copilot]

The fallback Docker build strategy assumes a specific project structure and Node.js setup that may not match the actual project. Consider validating the existence of package.json files before attempting the fallback build, or make the fallback more generic to handle different project types.

Suggested change

	echo "Build failed, creating minimal image..."
	cat > Dockerfile.minimal << EOF
	FROM node:18-alpine
	WORKDIR /app
	COPY ${{ matrix.service }}/package*.json ./
	RUN npm ci --only=production || npm install --production || echo "Install failed"
	EOF
	docker build -t connectkit-${{ matrix.service }}:sbom -f Dockerfile.minimal .
	echo "Build failed, checking for Node.js project files..."
	if ls ${{ matrix.service }}/package*.json 1> /dev/null 2>&1; then
	echo "Node.js project detected, creating minimal Node.js image..."
	cat > Dockerfile.minimal << EOF
	FROM node:18-alpine
	WORKDIR /app
	COPY ${{ matrix.service }}/package*.json ./
	RUN npm ci --only=production || npm install --production || echo "Install failed"
	EOF
	docker build -t connectkit-${{ matrix.service }}:sbom -f Dockerfile.minimal .
	else
	echo "No package.json found, creating generic minimal image..."
	cat > Dockerfile.minimal << EOF
	FROM alpine:3.18
	WORKDIR /app
	COPY ${{ matrix.service }} .
	EOF
	docker build -t connectkit-${{ matrix.service }}:sbom -f Dockerfile.minimal .
	fi

[Copilot]

Similar to the previous vulnerability counting issue, the TOTAL_COMPONENTS variable is being modified inside a subshell created by the for loop with glob expansion. The changes won't persist outside the loop. Use an array or process substitution approach to properly accumulate the component counts.

Suggested change

	TOTAL_COMPONENTS=$((TOTAL_COMPONENTS + COMPONENTS))
	fi
	done
	COMPONENT_COUNTS+=("$COMPONENTS")
	fi
	done
	TOTAL_COMPONENTS=0
	for count in "${COMPONENT_COUNTS[@]}"; do
	TOTAL_COMPONENTS=$((TOTAL_COMPONENTS + count))
	done