Security

This page covers security practices used in the B2C Developer Tooling project, with a focus on supply chain security.

Supply Chain Security

The JavaScript/Node.js ecosystem is particularly vulnerable to supply chain attacks due to the large number of transitive dependencies in typical projects. This project uses several pnpm features to mitigate these risks.

Minimum Release Age

New package versions are quarantined for 48 hours before they can be installed:

# pnpm-workspace.yaml
minimumReleaseAge: 2880  # minutes (48 hours)

This provides a buffer period during which:

• Malicious packages can be detected and removed from npm
• Security researchers can identify and report compromised packages
• The community can flag suspicious updates

If a package update is urgent, it can be added to the exclusion list:

minimumReleaseAgeExclude:
  - some-urgent-package

Trust Policy

Dependency downgrades are prevented to protect against downgrade attacks:

# pnpm-workspace.yaml
trustPolicy: no-downgrade

This ensures that once a package version is installed, it cannot be replaced with an older (potentially vulnerable) version without explicit action.

Restricting Build Scripts

Only explicitly allowed packages can run build scripts (install/postinstall hooks):

# pnpm-workspace.yaml
onlyBuiltDependencies:
  - unrs-resolver
  - yarn

Build scripts are a common attack vector because they execute arbitrary code during installation. By default, pnpm blocks all build scripts except for packages in this allowlist.

When adding a new dependency that requires build scripts:

1. Verify the package is legitimate and actively maintained
2. Review what the build script does
3. Add it to onlyBuiltDependencies if necessary

NPM Trusted Publishing

This project uses NPM trusted publishers for package publication. Instead of storing long-lived npm tokens, packages are published via GitHub Actions using short-lived OIDC tokens that cannot be extracted or reused.

Operational Security: Safety Mode

The CLI includes a Safety Mode feature via CLI checks and HTTP middleware that prevents accidental or unwanted destructive operations. This is particularly important when:

• Providing the CLI as a tool to AI agents/LLMs
• Working in production environments
• Training new team members
• Running commands from untrusted scripts

Safety Levels

Configure via the SFCC_SAFETY_LEVEL environment variable:

Level	Description	Blocks
NONE	No restrictions (default)	Nothing
NO_DELETE	Prevent deletions	DELETE operations
NO_UPDATE	Prevent deletions and destructive updates	DELETE + reset/stop/restart
READ_ONLY	Read-only mode	All writes (POST/PUT/PATCH/DELETE)

Usage

# Default - no restrictions
export SFCC_SAFETY_LEVEL=NONE

# Prevent deletions
export SFCC_SAFETY_LEVEL=NO_DELETE

# Prevent deletions and destructive updates
export SFCC_SAFETY_LEVEL=NO_UPDATE

# Read-only mode
export SFCC_SAFETY_LEVEL=READ_ONLY

Environment variables are used instead of command-line flags because LLMs control commands and flags, but not the environment.

Best Practices

For Contributors

• Review dependency updates carefully, especially for packages with build scripts
• Be cautious when adding new dependencies
• Prefer packages with minimal transitive dependencies
• Check package health on npm before adding (download counts, maintenance activity, known vulnerabilities)

For Users

• Keep the CLI updated to receive security patches
• Review the pnpm-workspace.yaml settings if you fork or modify this project
• Consider using similar protections in your own projects
• Use Safety Mode when running CLI in automated environments or providing it as a tool to AI agents