Supply Chain Security
How DFIRe's build and release pipeline defends against attacks that arrive through third-party software: compromised packages, hijacked maintainer accounts, and tampered build components.
Overview
DFIRe is security software, and software that investigates incidents must not become the incident. Every third-party component in a DFIRe release, whether a Python or JavaScript package, a container base image, or a build step, is treated as a potential attack path and gated accordingly. The layers:
| Layer | Protection |
|---|---|
| Version control | Every dependency, direct and transitive, pinned to an exact version |
| Integrity verification | Cryptographic hash verification on every package installed into a release |
| Install-time execution | Package install scripts disabled; packages cannot run code when installed |
| Adoption cooldown | New package versions must be at least 14 days old before adoption |
| Vulnerability auditing | Both ecosystems audited against known-vulnerability databases on every build |
| Build environment | Base images pinned by digest, build actions pinned by commit |
| Secret protection | Server-side push protection rejects commits containing credentials |
| Release gating | Images publish only after the full test and audit matrix passes |
Exact Pinning and Integrity Verification
Every dependency of a DFIRe release, direct and transitive, is pinned to an exact version in a lockfile. Nothing resolves "to the latest version" at build time, so a release built today and the same release built next month contain byte-identical dependencies.
Pinning alone does not stop a registry-side substitution, so installation verifies content, not just version numbers. Python packages install under mandatory SHA-256 hash verification: a package whose contents do not match the recorded hash is rejected. JavaScript packages install from a lockfile with per-package integrity hashes, and package signatures are additionally verified against the registry in CI.
JavaScript package install scripts are disabled entirely. Installing a package cannot execute code, so a malicious package that somehow entered the tree would sit inert on disk instead of running at install time, which is where most npm-based attacks detonate.
The 14-Day Adoption Cooldown
Most malicious package versions are detected and removed from public registries within days of publication. DFIRe therefore never adopts a package version younger than 14 days. Routine updates are proposed only after a version has aged through the window, and an independent CI gate re-checks every new or changed package version, direct and transitive, against the registry's own release records on every pull request.
The gate fails closed: if the registry evidence for a version cannot be verified, the change is rejected rather than assumed safe. Newly introduced prerelease versions and versions their maintainers have deprecated are rejected outright.
Exceptions Are Explicit and Expire
There is no automatic bypass, not even for security fixes. Adopting a version inside the 14-day window requires a written waiver that names the exact package, the versions involved, the specific artifact fingerprint, the reason, and an expiry date, and it must be approved by the maintainer. A waiver bypasses only the age check; hash, integrity, signature, and registry checks always remain in force.
Controlled Updates
Dependency updates arrive as automated pull requests that respect the cooldown; known-vulnerability fixes are proposed immediately but still pass the same gates or require an explicit waiver. New dependencies are never adopted silently: each one requires per-package maintainer approval before it enters the tree.
Every change to DFIRe, code or dependency, lands through a pull request with required status checks. Direct pushes to the release branches are rejected server-side, including for repository administrators.
Every build additionally audits both dependency ecosystems against known-vulnerability databases and fails on findings, so a release cannot ship with a known-vulnerable dependency unnoticed.
Build Environment Integrity
The build itself is part of the attack surface, so its components are pinned the same way the application's are. Container base images are referenced by immutable SHA-256 digest rather than floating tags, so a re-tagged upstream image cannot silently change what a DFIRe image is built from. Every CI action is pinned to a specific commit rather than a movable version tag, closing the common attack where a compromised action is slipped underneath an unchanged version label. Both are updated through the same reviewed pull request flow as application dependencies.
Secret Protection
The source repository enforces server-side secret scanning with push protection: a commit containing a credential is rejected at push time, before it can enter the repository history. This includes a custom detection pattern for DFIRe's own API key format, so a leaked DFIRe key is caught by the same gate as cloud and service credentials.
Release Gating and Transparency
Release images are built only when the complete test, lint, audit, and schema verification matrix passes; a failing gate means no image is published. New builds first publish to a testing channel, and promotion to the production release tag is a deliberate, manual step.
Every DFIRe deployment can show exactly what it is made of: Settings → Dependencies displays the full Python and JavaScript dependency manifests of the running version, including the verification hashes, and the manifests can be filtered and copied for your own compliance tooling. Third-party license information is published under Third-Party Licenses.
For the security architecture of the application itself, including encryption and access control, see Application Security.