JavaScript SBOM Generation Guide

Introduction: The JavaScript Dependency Challenge

JavaScript and Node.js are some of the easiest places to justify SBOM generation because even small apps can pull in very large transitive dependency trees through npm, yarn, or pnpm. That means vulnerability, license, and incident-response questions become hard to answer quickly unless you have a machine-readable dependency inventory.

Start Here

If you need the fastest reliable path:

• use the package manager lockfile as the source of truth
• generate CycloneDX first unless a downstream consumer requires SPDX
• handle monorepos deliberately instead of assuming one root lockfile tells the whole story
• validate the result before shipping it downstream

Common JavaScript commands

# npm
npm install -g @cyclonedx/cyclonedx-npm
cyclonedx-npm --output-format JSON --output-file bom.json

# validate the result in the browser
# https://sbomgenerator.com/tools/validator

Where JavaScript SBOMs usually go wrong

• stale lockfiles that do not match what CI actually installs
• monorepos with multiple package-manager roots
• dev dependency handling that differs between local and production builds
• package-manager-specific behavior between npm, yarn, and pnpm

Quick Start

Getting Started in Under 5 Minutes

The fastest way to generate an SBOM for a JavaScript project is using the CycloneDX tool, which has become the de facto standard for JavaScript SBOM generation. This approach works with any JavaScript project that has a package.json file, regardless of whether you use npm, yarn, or pnpm as your package manager.

Before running the commands below, ensure you are on a current supported Node.js LTS release. The CycloneDX tool will analyze your package-lock.json, yarn.lock, or pnpm-lock.yaml file to create a comprehensive inventory of all direct and transitive dependencies:

# Install CycloneDX CLI globally
npm install -g @cyclonedx/cyclonedx-npm

# Generate SBOM in your project directory
cyclonedx-npm --output-file bom.json

# This creates bom.json with your project's SBOM

Package Manager Support

Understanding JavaScript Package Managers

JavaScript projects can use different package managers, each with its own lock file format and dependency resolution algorithm. Understanding these differences is crucial for accurate SBOM generation. The three major package managers - npm, yarn, and pnpm - each have specific considerations for SBOM generation that we'll explore in detail.

npm Projects

For projects using npm (Node Package Manager), which is the default package manager for Node.js, you have several powerful options for SBOM generation. npm uses package-lock.json to lock dependency versions, ensuring reproducible builds. This lock file contains the exact dependency tree, including all transitive dependencies with their resolved versions, integrity hashes, and download locations.

When generating SBOMs for npm projects, it's important to understand that npm can have different dependency types: regular dependencies (used in production), devDependencies (used only during development), optionalDependencies (that won't break the install if they fail), and peerDependencies (that must be installed by the consuming project). Each type has different implications for your SBOM:

Using @cyclonedx/cyclonedx-npm

The @cyclonedx/cyclonedx-npm tool is specifically designed for JavaScript projects and provides the most comprehensive SBOM generation capabilities. It understands the nuances of npm's dependency resolution and can accurately represent complex dependency relationships. The tool generates SBOMs in the CycloneDX format, which is purpose-built for security use cases and includes rich metadata about vulnerabilities, licenses, and component relationships.

Here's how to use it effectively in your npm projects:

# Install the tool
npm install --save-dev @cyclonedx/cyclonedx-npm

# Generate SBOM (CycloneDX format)
npx @cyclonedx/cyclonedx-npm --output-file bom.json

# Specify output file
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# Omit development dependencies
npx @cyclonedx/cyclonedx-npm --output-file production-sbom.json --omit dev

Using Syft (Universal Tool)

Syft is a powerful universal SBOM generator that supports multiple ecosystems including JavaScript. While not JavaScript-specific like @cyclonedx/cyclonedx-npm, Syft offers advantages for organizations that need to generate SBOMs across different technology stacks. It can detect JavaScript packages through multiple methods: analyzing package.json and lock files, scanning node_modules directories, and even detecting packages in built JavaScript bundles.

Syft's strength lies in its ability to generate SBOMs in multiple formats (SPDX, CycloneDX, and its own format) and its deep integration with vulnerability scanning through Grype. Here's how to leverage Syft for JavaScript projects:

# Install Syft
curl -sSfL https://get.anchore.io/syft | sh

# Generate SBOM from package.json
syft dir:. -o cyclonedx-json=sbom.json

# Or analyze the entire directory
syft . -o spdx-json=sbom-spdx.json

Yarn Projects

Yarn was created by Facebook to address npm's performance and determinism issues, though npm has since caught up in many areas. Yarn introduces unique features like workspaces (monorepo support), Plug'n'Play (PnP) for faster installs, and zero-installs for committing dependencies. Each Yarn version has different implications for SBOM generation.

Yarn v1 (Classic)

Yarn Classic uses a yarn.lock file that's similar to npm's package-lock.json but with a different format. The lock file ensures deterministic installs across all environments. When generating SBOMs for Yarn v1 projects, the tools need to parse this specific format to accurately capture the dependency tree:

# Using @cyclonedx/cyclonedx-npm with Yarn
yarn add --dev @cyclonedx/cyclonedx-npm
yarn exec cyclonedx-npm --output-file bom.json

# Using yarn-audit-fix with SBOM generation
yarn audit --json | jq > vulnerabilities.json

Yarn v3+ (Berry)

Yarn Berry (v2 and later) represents a complete rewrite with significant changes including Plug'n'Play (PnP) by default, which eliminates node_modules in favor of a .pnp.cjs file. This architectural change affects how SBOM tools detect and analyze dependencies. Yarn Berry also introduces zero-installs, where dependencies are committed to the repository, changing the security and compliance considerations.

For Yarn Berry projects, SBOM generation requires tools that understand the PnP resolution strategy:

# Generate SBOM with modern Yarn
npx @cyclonedx/cyclonedx-npm --output-file yarn-sbom.json

# Or use the built-in audit
yarn npm audit --all --recursive --json

pnpm Projects

pnpm (performant npm) takes a unique approach to dependency management by using a content-addressable storage system. Instead of duplicating packages across projects, pnpm creates hard links from a global store, significantly reducing disk space and installation time. This architecture means that pnpm projects have a different node_modules structure (using .pnpm directories and symlinks) that SBOM tools must understand.

The pnpm-lock.yaml file contains the complete dependency tree with integrity hashes. When generating SBOMs for pnpm projects, it's crucial to use tools that can follow the symlink structure and accurately represent the actual dependencies being used:

# Install SBOM generator
pnpm add --save-dev @cyclonedx/cyclonedx-npm

# Generate SBOM
pnpm exec cyclonedx-npm

# Include workspace dependencies
pnpm exec cyclonedx-npm --include-workspace-root

Advanced Configuration

Customizing SBOM Generation for Your Needs

While basic SBOM generation provides valuable insights, most production environments require customization to meet specific security, compliance, and operational requirements. Advanced configuration allows you to control what's included in your SBOM, add organizational metadata, exclude certain packages, and integrate with your existing security toolchain.

CycloneDX Configuration

Here's a comprehensive configuration file that demonstrates the available options:

{
  "schemaVersion": "1.7",
  "output": {
    "file": "sbom.json",
    "format": "json"
  },
  "include": {
    "devDependencies": true,
    "optionalDependencies": true,
    "bundledDependencies": true
  },
  "exclude": {
    "patterns": [
      "@types/*"
    ]
  },
  "metadata": {
    "supplier": {
      "name": "Your Company",
      "url": "https://yourcompany.com"
    },
    "manufacture": {
      "name": "Your Company",
      "url": "https://yourcompany.com"
    }
  }
}

Custom Metadata

Adding custom metadata to your SBOMs is crucial for compliance and traceability. This metadata helps identify who created the software, when it was built, and under what conditions. For regulated industries, this information is often required for audit trails. Custom metadata can include supplier information, build environment details, approval signatures, and tool information.

The metadata you include should align with your organization's software governance policies and any regulatory requirements you must meet. Here's how to add comprehensive metadata to your SBOMs:

# Generate an SBOM with package metadata from package.json
npx @cyclonedx/cyclonedx-npm \
  --output-file sbom.json

Monorepo Support

Managing SBOMs in JavaScript Monorepos

Monorepos have become increasingly popular in JavaScript development, allowing teams to manage multiple related packages in a single repository. However, they present unique challenges for SBOM generation. Each package in a monorepo might have its own dependencies, and packages often depend on each other. Generating accurate SBOMs for monorepos requires understanding these inter-package relationships and deciding whether to generate individual SBOMs per package or a consolidated SBOM for the entire repository.

The key consideration is whether your packages are deployed independently or as a unit. For independently deployed packages, you'll want separate SBOMs. For applications that deploy together, a consolidated SBOM might be more appropriate.

Lerna Projects

Lerna is a popular tool for managing JavaScript monorepos, handling versioning, publishing, and dependency management across multiple packages. When generating SBOMs for Lerna projects, you need to consider both the workspace-level dependencies and individual package dependencies. Lerna's hoisting behavior, where shared dependencies are lifted to the root node_modules, affects how dependencies are resolved and should be reflected in your SBOMs:

# Generate SBOM for entire monorepo
npx @cyclonedx/cyclonedx-npm --include-workspace-root

# Generate individual SBOMs for each package
lerna exec -- npx @cyclonedx/cyclonedx-npm

Nx Workspaces

Nx provides powerful monorepo tooling with advanced features like computation caching, distributed task execution, and intelligent build orchestration. For SBOM generation in Nx workspaces, you can leverage Nx's task runner to generate SBOMs as part of your build pipeline. This integration ensures SBOMs are generated consistently and can be cached for performance.

Nx's project graph understands the relationships between your applications and libraries, which is valuable for generating accurate SBOMs that reflect actual usage patterns:

# Generate SBOM at workspace root
npx @cyclonedx/cyclonedx-npm

# Generate for specific project
npx nx run my-app:sbom

{
  "targets": {
    "sbom": {
      "executor": "@nrwl/workspace:run-commands",
      "options": {
        "command": "npx @cyclonedx/cyclonedx-npm --output-file dist/sbom.json"
      }
    }
  }
}

CI/CD Integration

Automating SBOM Generation in Your Pipeline

Integrating SBOM generation into your CI/CD pipeline ensures that every build produces an up-to-date SBOM, providing continuous visibility into your supply chain. Automated SBOM generation eliminates manual processes, reduces human error, and ensures compliance requirements are met consistently. The key is to generate SBOMs at the right points in your pipeline - after dependencies are installed but before deployment.

GitHub Actions

GitHub Actions provides an ideal platform for automated SBOM generation with its extensive marketplace of security actions and tight integration with GitHub's dependency graph and security features. When implementing SBOM generation in GitHub Actions, consider generating SBOMs for both pull requests (to catch issues early) and releases (for compliance and distribution).

Here's a comprehensive GitHub Actions workflow that demonstrates best practices:

name: Generate SBOM

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Generate SBOM
        run: |
          npm install -g @cyclonedx/cyclonedx-npm
          cyclonedx-npm --output-file sbom.json

      - name: Upload SBOM
        uses: actions/upload-artifact@v3
        with:
          name: sbom
          path: sbom.json

      - name: Scan for vulnerabilities
        run: |
          npm install -g @cyclonedx/cdx-cli
          cdx-cli validate --input-file sbom.json

GitLab CI

stages:
  - build
  - security

generate-sbom:
  stage: security
  image: node:18
  script:
    - npm ci
    - npm install -g @cyclonedx/cyclonedx-npm
    - cyclonedx-npm --output-file sbom.json
  artifacts:
    reports:
      cyclonedx: sbom.json
    paths:
      - sbom.json
    expire_in: 1 week

Azure Pipelines

- task: NodeTool@0
  inputs:
    versionSpec: '18.x'
  displayName: 'Install Node.js'

- script: |
    npm ci
    npm install -g @cyclonedx/cyclonedx-npm
    cyclonedx-npm --output-file $(Build.ArtifactStagingDirectory)/sbom.json
  displayName: 'Generate SBOM'

- task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: '$(Build.ArtifactStagingDirectory)/sbom.json'
    artifactName: 'sbom'

Docker Integration

Multi-stage Build with SBOM

# Build stage
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

# SBOM generation stage
FROM node:18-alpine AS sbom-generator
WORKDIR /app
COPY package*.json ./
COPY --from=builder /app/node_modules ./node_modules
RUN npm install -g @cyclonedx/cyclonedx-npm
RUN cyclonedx-npm --output-file sbom.json

# Final stage
FROM node:18-alpine AS runtime
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY --from=sbom-generator /app/sbom.json ./sbom.json
COPY . .
EXPOSE 3000
CMD ["node", "index.js"]

Container SBOM Generation

# Build your container
docker build -t myapp:latest .

# Generate SBOM from the built container
syft myapp:latest -o cyclonedx-json=container-sbom.json

# Or use Docker's built-in SBOM support
docker buildx build --sbom=true -t myapp:latest .

Framework-Specific Examples

React Applications

# Create React App
npx create-react-app my-app
cd my-app

# Install SBOM generator
npm install --save-dev @cyclonedx/cyclonedx-npm

# Add to package.json scripts
{
  "scripts": {
    "sbom": "cyclonedx-npm --output-file public/sbom.json",
    "build": "react-scripts build && npm run sbom"
  }
}

# Generate SBOM
npm run sbom

Next.js Applications

# Install SBOM tool
npm install --save-dev @cyclonedx/cyclonedx-npm

# Add to next.config.js
module.exports = {
  webpack: (config, { buildId, dev, isServer, defaultLoaders, webpack }) => {
    if (!dev && !isServer) {
      // Generate SBOM during production build
      const { execSync } = require('child_process');
      execSync('npx @cyclonedx/cyclonedx-npm --output-file .next/static/sbom.json');
    }
    return config;
  },
}

Express.js Applications

# In your Express app
npm install --save-dev @cyclonedx/cyclonedx-npm

# Add SBOM endpoint
app.get('/sbom', (req, res) => {
  const sbom = require('./sbom.json');
  res.json(sbom);
});

# Generate SBOM on deployment
npm run build && cyclonedx-npm

Vulnerability Scanning

Integration with Security Tools

# Generate SBOM and scan for vulnerabilities
cyclonedx-npm --output-file sbom.json

# Use npm audit
npm audit --json >> audit-results.json

# Use Snyk
npx snyk test --file=package.json --json >> snyk-results.json

# Use OSV Scanner
osv-scanner --sbom sbom.json

Automated Security Monitoring

// security-check.js
const fs = require('fs');
const { execSync } = require('child_process');

// Generate fresh SBOM
execSync('cyclonedx-npm --output-file sbom.json');

// Read SBOM
const sbom = JSON.parse(fs.readFileSync('sbom.json', 'utf8'));

// Check for known vulnerable packages
const vulnerablePackages = [
  'event-stream@3.3.6',
  'flatmap-stream@0.1.1'
];

sbom.components.forEach(component => {
  const packageString = `${component.name}@${component.version}`;
  if (vulnerablePackages.includes(packageString)) {
    console.error(`⚠️  Vulnerable package detected: ${packageString}`);
    process.exit(1);
  }
});

console.log('✅ No known vulnerable packages found');

Best Practices

Essential Best Practices for JavaScript SBOM Generation

Implementing SBOM generation effectively requires more than just running tools - it requires establishing processes and standards that ensure consistency, accuracy, and maintainability. These best practices have been developed through real-world experience managing JavaScript projects at scale, from small startups to enterprise applications with millions of users.

1. Regular Generation

The most critical best practice is generating SBOMs regularly, not just during releases or security audits. Dependencies in the JavaScript ecosystem change rapidly - the average npm package releases a new version every 11 days. By generating SBOMs with every build, you maintain continuous visibility into your supply chain.

Automating SBOM generation through git hooks ensures consistency and prevents human error. Pre-commit hooks can generate SBOMs before code is committed, while post-merge hooks can update SBOMs when dependencies change:

# Add pre-commit hook
echo "cyclonedx-npm --output-file sbom.json" > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit

2. Version Control

Deciding whether to commit SBOMs to version control is a important architectural decision. Committing SBOMs provides an audit trail and allows you to track how dependencies change over time. However, SBOMs can be large (several MB for complex projects) and change frequently, potentially bloating your repository.

The recommended approach depends on your compliance requirements and deployment model. For regulated industries or projects requiring strict audit trails, commit SBOMs. For rapid development environments, generate SBOMs in CI/CD:

# .gitignore
# Include SBOM in version control for transparency
# but consider size implications
sbom.json

# Or exclude and generate in CI/CD
# !sbom.json

3. Dependency Pinning

Pinning dependencies to exact versions ensures reproducible builds and consistent SBOMs. While using version ranges (^1.0.0 or ~1.0.0) allows automatic updates, it can introduce unexpected changes and security vulnerabilities. Pinning versions gives you control over when dependencies update, allowing you to review changes and their security implications.

However, pinning requires active dependency management to avoid falling behind on security updates. Use tools like Renovate or Dependabot to automate dependency updates with proper testing:

{
  "dependencies": {
    "express": "4.18.2",
    "lodash": "4.17.21"
  },
  "devDependencies": {
    "@cyclonedx/cyclonedx-npm": "^4.0.0"
  }
}

4. SBOM Validation

Validating generated SBOMs ensures they meet format specifications and contain required information. Invalid SBOMs can cause issues with security tools, compliance audits, and downstream consumers. Validation should check both syntactic correctness (valid JSON/XML) and semantic completeness (required fields present).

Implement validation as part of your CI/CD pipeline to catch issues early:

# Validate generated SBOM
npm install -g @cyclonedx/cdx-cli
cdx-cli validate --input-file sbom.json --format json

Troubleshooting

Common Issues and Solutions

Even with proper setup, you may encounter issues when generating SBOMs for JavaScript projects. These problems often stem from the complexity of the npm ecosystem, edge cases in dependency resolution, or tool limitations. This troubleshooting guide addresses the most common issues with practical solutions.

This is the most common issue, usually caused by inconsistencies between package.json and lock files, or tools not detecting certain dependency types. The problem often occurs after dependency updates or when switching between package managers:

# Ensure all dependencies are installed
npm ci
rm -rf node_modules package-lock.json
npm install
cyclonedx-npm

JavaScript applications can have thousands of dependencies, leading to large SBOMs that are difficult to manage and analyze. This issue is particularly acute in projects using frameworks like React or Angular, which bring in extensive dependency trees:

# Exclude dev dependencies in production
cyclonedx-npm --output-file production-sbom.json --omit dev

# Analyze bundle
npm install -g webpack-bundle-analyzer
npx webpack-bundle-analyzer build/static/js/*.js

Many organizations use private npm registries for internal packages. SBOM tools may not have access to these registries, resulting in incomplete SBOMs or generation failures. This requires configuring authentication and ensuring tools respect npm's registry configuration:

# Generate a test SBOM after authenticating to your private registry
cyclonedx-npm --output-file private-registry-sbom.json

Frequently Asked Questions (FAQ)

General JavaScript SBOM Questions

A: CycloneDX is generally recommended for JavaScript projects as it was designed specifically for modern application security use cases and has better support for npm-specific metadata like package managers, registries, and JavaScript-specific vulnerability information. However, if you need to comply with specific regulations that require SPDX (like some government contracts), or need to integrate with tools that only support SPDX, then SPDX is the better choice. Many organizations generate both formats to ensure maximum compatibility.

A: It depends on your use case. For production deployments, you typically want to exclude devDependencies since they're not part of the deployed application. However, for security analysis and compliance, including devDependencies can be valuable as they might introduce vulnerabilities during the build process. Best practice is to generate two SBOMs: one for production (without devDependencies) and one comprehensive SBOM (with all dependencies) for security analysis.

A: Minified and bundled JavaScript presents challenges for SBOM generation since the original package structure is obscured. The best approach is to generate SBOMs during the build process before bundling, when you still have access to the full dependency tree. Tools like Webpack and Rollup can be configured to output dependency information that can be converted to SBOM format. For existing bundles, tools like Syft can attempt to identify packages through pattern matching, though results may be incomplete.

Tool-Specific Questions

A: Different tools use different detection methods. @cyclonedx/cyclonedx-npm reads package lock files and package.json directly, providing npm-specific accuracy. Syft uses multiple catalogers and can detect packages through various methods including file system scanning. Differences often occur with bundled dependencies, git dependencies, or packages installed via unusual methods. For JavaScript projects, @cyclonedx/cyclonedx-npm typically provides more accurate results.

A: Authentication depends on the tool. For @cyclonedx/cyclonedx-npm, it respects npm's configuration including .npmrc files and environment variables. Ensure you have proper authentication set up:

npm config set @company:registry https://npm.company.com
npm config set //npm.company.com/:_authToken YOUR_TOKEN

For Syft, you may need to configure registry authentication separately in its configuration file.

A: Yes, both React Native and Electron applications use npm/yarn for dependency management, so standard JavaScript SBOM tools work. However, consider that these applications may include native dependencies (iOS/Android for React Native, native Node modules for Electron) that require additional scanning. Use platform-specific tools in conjunction with JavaScript SBOM generators for complete coverage.

Security and Compliance Questions

A: Best practice is to generate SBOMs with every build in CI/CD. At minimum, regenerate SBOMs when: dependencies change (including transitive updates), before releases, after security patches, and during security audits. For actively developed projects, daily SBOM generation helps track dependency drift. For production systems, generate SBOMs for each deployed version.

A: Global npm packages and CDN-loaded libraries are often missed by standard SBOM tools since they're not in package.json. Document these separately and include them manually in your SBOM or maintain a supplementary inventory. For CDN dependencies, consider using Subresource Integrity (SRI) hashes and documenting specific versions. Some organizations move CDN dependencies to npm to ensure they're captured in SBOMs.

npx license-checker --json --out licenses.json

Review licenses for compatibility with your project's license. Pay special attention to copyleft licenses (GPL, AGPL) if you're building proprietary software. Consider using automated license scanning in CI/CD to catch problematic licenses early.

Advanced Use Cases

SBOM Diff for Updates

Comparing SBOMs before and after dependency updates helps identify what changed and assess security impact. This is particularly valuable for understanding the full impact of updating a major dependency, which might bring in numerous transitive dependency changes:

# Generate baseline SBOM
cyclonedx-npm --output-file sbom-before.json

# Update dependencies
npm update

# Generate new SBOM
cyclonedx-npm --output-file sbom-after.json

# Compare SBOMs (requires custom tooling)
node compare-sboms.js sbom-before.json sbom-after.json

License Compliance

Managing license compliance in JavaScript projects requires understanding both direct and transitive dependency licenses. With hundreds or thousands of dependencies, manual review is impractical. Automated license analysis using SBOMs helps identify potential legal risks before they become problems:

# Generate SBOM with license information
cyclonedx-npm --output-file sbom-with-licenses.json

# Extract licenses
jq '.components[].licenses' sbom-with-licenses.json

Integration with Security Tools

SBOMs become more valuable when integrated with security tools for continuous monitoring. Many organizations pipe SBOM data into their security information and event management (SIEM) systems or vulnerability management platforms. This integration enables automated alerting when new vulnerabilities affect your dependencies:

# Send SBOM to security platform
cyclonedx-npm --output-file - | \
  curl -X POST https://security.company.com/api/sbom \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $API_TOKEN" \
    --data @-

Conclusion

Generating accurate SBOMs for JavaScript projects is essential for modern software security and compliance. The JavaScript ecosystem's complexity, with its deep dependency trees and rapid evolution, makes automated SBOM generation crucial. By following the practices and patterns in this guide, you can implement robust SBOM generation that provides continuous visibility into your software supply chain.

Remember that SBOM generation is not a one-time activity but an ongoing process. As your application evolves and the threat landscape changes, your SBOM practices should evolve too. Start with basic generation, then progressively add validation, security scanning, and automation as your processes mature.

Supply Chain Analysis

// analyze-supply-chain.js
const sbom = require('./sbom.json');

const analysis = {
  totalComponents: sbom.components.length,
  uniquePublishers: new Set(sbom.components.map(c => c.publisher)).size,
  licenseTypes: new Set(sbom.components.flatMap(c => 
    (c.licenses || []).map(l => l.license?.id)
  )).size,
  oldestComponent: sbom.components.reduce((oldest, current) => 
    new Date(current.modified || 0) < new Date(oldest.modified || 0) 
      ? current : oldest
  )
};

console.log('Supply Chain Analysis:', analysis);

This comprehensive guide covers everything you need to know about generating SBOMs for JavaScript and Node.js projects. The key is to integrate SBOM generation into your development workflow early and automate the process through CI/CD pipelines.