Malicious code introduced in SecureDrop repository mitigated

THREAT28 · Mitigated: Controls in place bring the risk down to an acceptable level. · Defined in catalog.py:491

Risk
High impact × Low likelihood = 6 medium
After mitigations
High impact × Very Low likelihood = 3 low

How statuses and scores work

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

Where it applies

Applies to 1 component in 1 scenario.

Supply chain and dependencies · SecureDrop source repository

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). Automated test for mitigation: Yes.

How this threat is matched

Listed for these components. A boundary covers every component inside it.