Security
Supply chain
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.
What is defended, and against what
Software that investigates incidents must not become one. DFIRe therefore treats every third-party component as a possible way in, whether it is a Python or JavaScript package, a container base image or a build step. Eight gates stand between such a component and a release.
| 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 |
Pinning and integrity
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 a version does not stop a registry swapping what sits behind it, so installation checks content rather than version numbers. Python packages install under mandatory SHA-256 verification, and a package whose contents disagree with the recorded hash is rejected. JavaScript packages install from a lockfile carrying an integrity hash each, and CI verifies their signatures against the registry.
JavaScript install scripts are switched off entirely, so installing a package cannot run code. A malicious package that reached the tree would sit inert on disk rather than executing at install time, which is where most npm attacks fire.
The 14-day 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 once a version has aged through the window. An independent CI gate then re-checks every new or changed version, direct and transitive, against the registry's own release records on every pull request.
The gate fails closed. Registry evidence that cannot be verified means the change is rejected rather than assumed safe, and a newly introduced prerelease or a version its maintainer has deprecated is rejected outright.
Exceptions are written down and expire
There is no automatic bypass, not even for security fixes. Adopting a version inside the window takes a written waiver, approved by the maintainer, naming the package, the versions involved, the artifact fingerprint, the reason and an expiry date. A waiver lifts the age check alone. The hash, integrity, signature and registry checks stay in force.
How updates arrive
Dependency updates arrive as automated pull requests that respect the cooldown. A known-vulnerability fix can be proposed at once, but it still passes the same gates or carries an explicit waiver. No new dependency enters the tree without the maintainer approving that package by name.
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 audits both ecosystems against known-vulnerability databases and fails on a finding, so no release ships with a known-vulnerable dependency unnoticed.
The build environment
The build is part of the attack surface, so its own components are pinned the same way. Base images are referenced by immutable SHA-256 digest rather than by tag, so a re-tagged upstream image cannot change what DFIRe is built from.
Every CI action is pinned to a commit rather than a version tag. That closes the familiar attack where a compromised action slips in underneath an unchanged label. Both kinds of pin update through the same reviewed pull request as any dependency.
Secrets never reach the repository
The repository scans pushes server-side and rejects a commit carrying a credential before it can reach the history. A custom pattern covers DFIRe's own API key format, so a leaked DFIRe key meets the same gate as a cloud or service credential.
What gates a release
An image is built only when the whole matrix passes: tests, lint, audits and schema verification. A failing gate means no image. New builds reach a testing channel first, and promoting one to a release tag is a deliberate manual step.
Every deployment can show what it is made of. Settings → Dependencies lists the full Python and JavaScript manifests of the running version with their verification hashes, filterable and copyable 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.