Malicious code introduced in SecureDrop release mitigated
THREAT29
· Mitigated: Controls in place bring the risk down to an acceptable level.
· Defined in catalog.py:508
- Risk
- High impact × Low likelihood = 6 medium
- After mitigations
- High impact × Very Low likelihood = 3 low
An attacker could masquerade a contribution or accidentally insert malicious code to subvert the application (e.g. backdoor, faulty logic ...)
Threat actors: Malicious developer Developer error
Mitigations
| Mitigation | Status |
|---|---|
| All SecureDrop and tor releases (Release file and tag) signed with airgapped key MITIG46 | implemented |
| Airgapped signing for release tags, public and controlled branches for development/release MITIG77 | implemented |
| 2FA required for SD maintainer GitHub accounts MITIG176 | implemented |
| All code is reviewed prior to merge MITIG47 | implemented |
| SecureDrop code is open source MITIG177 | implemented |
Possible further mitigations
- Mandate all signed commits MITIG231 proposed
- Use hardware-backed token for SSH key auth to Github MITIG232 proposed
- Shard SecureDrop release key MITIG233 proposed
Where it applies
Applies to 1 component in 1 scenario.
Supply chain and dependencies · SecureDrop release & package build
Notes
Existing mitigations: Signed code, signed releases (we sign the release tag with the airgap key) (MITIG46), develop (trunk for us) branch protection (MITIG77), 2-factor mandated (MITIG176), code owners, code reviews (MITIG47). External contributors and users may also audit the code (MITIG177). Further mitigations: Additional code reviewers. Mandate the use of hardware-backed GPG keys and GPG signing for all commits to the SecureDrop repository (MITIG231). Also consider using an additional hardware-backed token for SSH key (MITIG232). Split SecureDrop release key among multiple maintainers, require N-person rule for release (MITIG233). Automated test for mitigation: No.
How this threat is matched
Listed for these components. A boundary covers every component inside it.