Integrity and supply chain
What is this about?
All other safeguards assume that the running code matches the checked state. That is why we detect later changes to the code, separate permissions and release only what has passed the check pipeline. Part of the hardening of the delivery is still open; this is stated in the monthly report.
Protection goal
Nobody should be able to change code unnoticed or release it past the checking process, neither through an attack nor through a tampered package.
How it works
- Reference listing: At delivery, a checksum of every program file is recorded. A command can compare the running state with it. Changed, new or removed files count as a violation and are logged. If the reference listing is missing, that is an error in itself.
- Separated permissions: The application works in the database with the permissions it needs, and with separate roles for different tasks.
- Checked delivery: Changes reach the main state only through the check pipeline. Only what has passed the check pipeline is released to the beta.
- Dependencies: The libraries in use are checked for known vulnerabilities and licenses.
Measures
- We record checksums of the program files so that later changes can be detected.
- We separate database roles so that one part of the application cannot see more than it needs.
- The main state is protected: changes need the mandatory checks before they are accepted.
- The dependency check runs on every change. We also search for credentials committed by accident, check licenses and produce a bill of materials of the libraries used at each release.
What we do not promise
- The checksums notice a change; they do not prevent it.
- The further hardening of the delivery is still open. Details are in the monthly report.
- The dependency check knows only vulnerabilities that are already known.
How we check this
The detection of file changes has automated tests, which the table below names. The “Deployment Integrity” scenario is listed in the monthly report as a known remaining measure.
Evidence tests
| Test | What the test proves |
|---|---|
IntegrityVerifyCommandTest |
Changed, new and removed files are detected, and a missing reference listing counts as an error. |
SecurityTestManifestCoverageTest |
Every security test class named as mandatory really exists as a file. |
Change history
- : First version.