sf-audit-plugin

Semantic versioning with a documented release process, and a CHANGELOG entry per release stating whether behaviour changed and what the upgrade impact is.

The project uses the GitHub issue tracker at https://github.com/cclabsnz/sf-audit-plugin/issues for tracking individual issues. It is public, searchable, and permanently addressable per issue, covering both open and closed reports. The process for submitting a report is documented in CONTRIBUTING.md under 'Reporting bugs and requesting features', and issue templates are configured under .github/ISSUE_TEMPLATE. Feature requests and defects are tracked in the same place, so a reader can see the full history of what has been raised and how it was resolved.

No vulnerabilities have been reported or resolved in the last 12 months, so there is no reporter to credit. The standing commitment is published at https://github.com/cclabsnz/sf-audit-plugin/blob/main/SECURITY.md which states that a reporter will be credited in the release notes unless they ask to remain anonymous. The private reporting channel is https://github.com/cclabsnz/sf-audit-plugin/security/policy

https://github.com/cclabsnz/sf-audit-plugin/blob/main/SECURITY.md — private reporting via GitHub or a dedicated address, a 5 business day acknowledgement commitment, and coordinated disclosure.

https://github.com/cclabsnz/sf-audit-plugin/blob/main/CONTRIBUTING.md#coding-standards . TypeScript strict plus noUnusedLocals, noUnusedParameters and noFallthroughCasesInSwitch are compile errors; oxlint covers correctness classes the compiler does not model.

pnpm run lint (oxlint, configured in .oxlintrc.json) runs in CI on every push and pull request, in the build-test job which is a required status check on main. The compiler flags above are enforced by the same gate.

There is no C/C++ toolchain: the build is a single tsc invocation driven by npm scripts, so CC/CFLAGS-style variables do not apply.

tsconfig.json sets sourceMap and declarationMap true, so compiled output carries source maps for debugging.

One tsc invocation over the whole project; there is no recursive make.

pnpm install --frozen-lockfile with a committed lockfile, then a single deterministic tsc invocation. CI builds from the same lockfile, and prepack rebuilds before publish so the published artefact is always compiled from the source at that commit.

sf plugins install @cclabsnz/sf-audit, the standard mechanism for Salesforce CLI plugins. Also installable from npm. Uninstall via sf plugins uninstall.

Installation is handled by npm and the Salesforce CLI plugin mechanism; there is no bespoke installer with prefix/DESTDIR semantics.

https://github.com/cclabsnz/sf-audit-plugin/blob/main/docs/INSTALL.md and the Development section of the README: git clone, npm install, npm run build, sf plugins link .

Dependencies are declared machine-readably in https://github.com/cclabsnz/sf-audit-plugin/blob/main/package.json and pinned with integrity hashes in a committed lockfile at https://github.com/cclabsnz/sf-audit-plugin/blob/main/pnpm-lock.yaml . Every release also ships a CycloneDX SBOM generated in CI and attached to the GitHub Release at https://github.com/cclabsnz/sf-audit-plugin/releases . Transitive packages with known advisories are pinned through the overrides block in package.json, so those pins are auditable rather than implicit.

Dependabot on production and development groups, a pnpm audit gate in CI, and a PR dependency-review gate covering both vulnerabilities and a copyleft-licence policy.

No vendored or forked copies of dependencies. Everything is a normal npm dependency, upgradable independently. The overrides block pins transitive packages with known advisories and is documented.

https://github.com/cclabsnz/sf-audit-plugin/blob/main/docs/COMMANDS.md documents every flag of every command and is kept in step with the code.

GitHub Actions runs lint, build, typecheck and the full Jest suite on every push and pull request; build-test is a required status check on main.

Bug fixes ship with a test that fails without the fix, per the stated testing policy. Recent example: the MessagingChannel field fix added a regression guard asserting the query uses MessageType and never ChannelType, the exact error that made the check silently return nothing.

80.1% statement coverage measured with jest --coverage: 4016 of 5013 statements, across 110 suites and 1008 tests.

Formally required, not advisory. https://github.com/cclabsnz/sf-audit-plugin/blob/main/CONTRIBUTING.md#testing-policy states that every change adding or altering behaviour ships with automated tests in the same pull request, that new checks require a unit test with mocked clients, and that bug fixes require a test that fails without the fix. It is enforced by build-test being a required status check on main, so a pull request whose tests do not pass cannot merge.

The policy is stated in the instructions for change proposals: https://github.com/cclabsnz/sf-audit-plugin/blob/main/CONTRIBUTING.md#testing-policy requires that every change adding or altering behaviour ships with automated tests in the same pull request, that a new check requires a unit test with mocked SOQL/Tooling/REST clients, and that a bug fix requires a test which fails without the fix. It sits immediately before the pre-pull-request checklist, which also requires a green npm test, and build-test is a required status check on main so the policy is enforced rather than merely stated.

The project is maximally strict where practical: tsconfig.json enables strict, noUnusedLocals, noUnusedParameters, noFallthroughCasesInSwitch and isolatedModules, and these are compile ERRORS rather than warnings, so code that trips them cannot build. Because tests are transformed with swc (which strips types without checking them), a separate tsc --noEmit pass over src and test runs ahead of Jest in npm test, so the strictness applies to the test tree too. oxlint adds correctness rules the compiler does not model. All of it runs in the build-test job, a required status check on main. Enabling these flags surfaced thirteen real dead-code findings, which were removed rather than suppressed.

Least privilege (read-only, does not require View All Data), a single narrow org boundary through four client interfaces, fail-safe defaults (an unreadable source reports inconclusive rather than a pass), and no network destination other than the authenticated org. The argument and its evidence are in docs/ASSURANCE-CASE.md

The project implements no cryptography and selects no algorithms; transport security is provided by Node.js TLS via the Salesforce SDK.

No cryptographic algorithms are selected or configured by this project.

No credentials are stored by the tool at all. It uses the Salesforce CLI's existing authenticated connection, and publishing uses short-lived OIDC credentials rather than a stored token.

All org communication is HTTPS via the Salesforce SDK. A test fails the build on any raw node:http/https use or third-party HTTP client.

TLS is negotiated by Node.js and the Salesforce SDK, which use modern TLS by default; the project does not downgrade or override it.

Certificate verification is the Node.js and SDK default and is never disabled: there is no rejectUnauthorized:false or NODE_TLS_REJECT_UNAUTHORIZED anywhere in the source.

The only host contacted is the authenticated org, over verified TLS, before any credential-bearing header is sent.

Releases are published from CI via npm Trusted Publishing (OIDC) with build provenance, so the published tarball carries a signed attestation linking it to the exact public commit. Verify with: npm audit signatures

Scoring configuration supplied by the user is parsed and validated with a zod schema before use. Data returned by the org is treated as untrusted and escaped on output: generated HTML escapes all interpolated values, and a test asserts reports contain no remote assets.

The software is hardened against its own defects turning into vulnerabilities. It is strictly read-only against the target org, enforced by a static invariant test that fails the build on any of seven org-mutation patterns, so a coding mistake cannot become a write. A second invariant forbids third-party HTTP clients, raw node:http/https, telemetry endpoints and remote assets in generated reports, so a mistake cannot become an exfiltration path. Generated HTML escapes every interpolated value. There is no eval, no dynamic require and no shelling out. Checks fail safe: an unreadable source reports inconclusive rather than a pass. Node runs with default TLS verification, never disabled.

https://github.com/cclabsnz/sf-audit-plugin/blob/main/docs/ASSURANCE-CASE.md — a narrow top-level claim, six sub-claims each with executable evidence, and an explicit section on what the case does not claim.

Two independent tools, both targeting common vulnerability classes rather than style. GitHub CodeQL runs with the security-extended query suite over both the TypeScript source and the CI workflow definitions (languages: javascript-typescript and actions), covering injection, path traversal, unsafe deserialisation and similar. Semgrep runs with p/owasp-top-ten and p/security-audit alongside p/default and p/typescript. Both execute on every push and every pull request, plus a weekly scheduled run, and upload SARIF to GitHub code scanning. Findings are triaged and either fixed or dismissed with a public recorded reason.

The project produces no code in a memory-unsafe language. It is TypeScript executing on Node.js.