BytesafeDependency Firewall

Scan for secrets on publish

Block publishes of packages that contain leaked credentials, scanned on the upload phase.

The secrets selector function scans the contents of a package being published for leaked credentials: cloud provider keys, API tokens, private keys, and the firewall's own access tokens. It runs on the upload phase only, so a matching block rule rejects the publish before it reaches the publish target. It applies to the ecosystems that accept publishes through the firewall: npm, PyPI, Maven, and NuGet.

Detection covers several hundred credential formats, plus Bytesafe's own token formats, so a package that would leak the very token used to publish it is caught too. Matched secret values are redacted before anything is logged; the raw secret never appears in a log entry.

Add the rule

In the dashboard, open the firewall, go to Rules, and create a rule:

  • Execution phase: upload
  • Selector function: Secrets
  • Effect: block and log

As JSON:

{
  "id": "block-secrets-on-publish",
  "executionPhase": "upload",
  "selector": {
    "function": {
      "name": "secrets",
      "options": { "ignoredFiles": [], "excludeTestFiles": false }
    }
  },
  "ruleEffect": { "block": true, "log": true },
  "description": "Block publishes containing leaked credentials"
}

options can be omitted entirely; both fields default to off. To apply the JSON without the dashboard: export the config with bsfw config export, add the rule to the rules array, and import it back. See config import.

If your teams publish frequently and you want to gauge the false positive rate first, start with { "block": false, "log": true } and watch the log for a few days before enabling block.

What a match looks like

The rule matches when at least one potential secret remains after the options below are applied. The publish is rejected with an error naming the block (see your ecosystem page for what the client shows), and the log entry's message reads:

2 potential secrets detected

The log entry's rule output lists each finding with the matched rule, the file path within the package, the line, and a fingerprint. The secret value itself is always REDACTED:

{
  "message": "2 potential secrets detected",
  "findingsTotal": 2,
  "truncated": false,
  "findings": [
    {
      "rule": "aws-access-token",
      "file": "package/config/prod.env",
      "line": 12,
      "secret": "REDACTED",
      "fingerprint": "package/config/prod.env:aws-access-token:12"
    },
    {
      "rule": "bytesafe-personal-access-token",
      "file": "package/scripts/publish.sh",
      "line": 3,
      "secret": "REDACTED",
      "fingerprint": "package/scripts/publish.sh:bytesafe-personal-access-token:3"
    }
  ]
}

The findings list is capped at 20 entries; findingsTotal and truncated carry the full count. Paths inside nested archives are separated by !.

Handle false positives

Secret detection is pattern-based, so example keys in documentation or test fixtures can match. Fix the finding at the source when you can: a credential that only looks fake is indistinguishable from a real one to everyone downstream. When the content is intentional, the rule has two options to ignore it:

OptionDashboard labelMeaning
ignoredFilesIgnored FilesList of file paths whose findings are ignored. Use the path exactly as shown in the log entry's file field. Each pattern is an exact path or has a single leading or trailing * wildcard; for example package/docs/* or *.pem. Paths are always matched case-sensitively
excludeTestFilesIgnore findings in test filesIgnore findings in paths that look like test content: a path segment named test, tests, __tests__, spec, specs, testdata, or fixtures, or a file name ending in _test, .test, or .spec before its extension

Prefer these options over an exception: an exception waives the whole rule for the matching package, options only silence the named findings. Use an exception when a specific package must go out now and you will clean it up after.

Limits

  • Artifacts larger than 256 MB are not scanned.
  • A scan is bounded to 30 seconds.
  • Archives nested inside the package are scanned three levels deep, and base64-encoded content is decoded up to three levels, so encoded credentials are still found.
  • JavaScript and CSS source maps (*.js.map, *.css.map, and similar) are skipped: their embedded sourcesContent duplicates the shipped sources, where a real secret would also be found.

Verify

Publish a throwaway package containing a documented example credential, such as AWS's example access key ID AKIAIOSFODNN7EXAMPLE, through the firewall. The publish should be rejected, and the log entry should show the finding with the file and line. Never use a real credential to test.

On this page