i-probably-didnt-backdoor-this
in-toto
i-probably-didnt-backdoor-this | in-toto | |
---|---|---|
5 | 4 | |
148 | 841 | |
- | 2.5% | |
0.0 | 8.9 | |
9 months ago | 4 days ago | |
Dockerfile | Python | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
i-probably-didnt-backdoor-this
-
Can rustc generate identical binaries, with the same hash, from the same souce code?
It's well explored for Linux (I wrote documentation for this in the past: https://github.com/kpcyrd/i-probably-didnt-backdoor-this)
- I-probably-didnt-backdoor-this – experiment on supply-chain security
- A practical experiment on supply-chain security using reproducible builds
- Using Reproducible Builds to reproduce 3rd party packages
- i-probably-didnt-backdoor-this: Using Reproducible Builds to verify a Rust Binary
in-toto
-
UEFI Software Bill of Materials Proposal
The things you mentioned are not solved by a typical "SBOM" but e.g. CycloneDX has extra fields to record provenance and pedigree and things like in-toto (https://in-toto.io/) or SLSA (https://slsa.dev/) also aim to work in this field.
I've spent the last six months in this field and people will tell you that this or that is an industry best practice or "a standard" but in my experience none of that is true. Everyone is still trying to figure out how best to protect the software supply chain security and things are still very much in flux.
-
An Overview of Kubernetes Security Projects at KubeCon Europe 2023
in-toto is an open source project that focuses on the attestation part of software supply chain security. You use it to define a “layout” for a project, i.e., how the different components should fit together. A project ships this definition with its code, and then another user of that software can compare what they have with the attached definition to see if it matches the structure and contents they expect. If it doesn’t, then this could point to external tampering or other issues.
-
How do you mitigate supply chain attacks?
But it's not all doom and gloom because the industry is evolving. Companies like Google are formulating tools like scorecard to heuristically reduce risk by encouraging you to rely on trustable dependencies only. There's also more complex tools like in-toto that actually look at the integrity of your supply chain (don't ask me how this one works, I just know that people like it).
- in-toto/in-toto: in-toto is a framework to protect supply chain integrity.
What are some alternatives?
nginx-waf - Nginx + ModSecurity WAF
snyk - Snyk CLI scans and monitors your projects for security vulnerabilities. [Moved to: https://github.com/snyk/cli]
docker-bloodhound - BloodHound Docker Ready to Use
scorecard - OpenSSF Scorecard - Security health metrics for Open Source
platform_external_vanadium - Vanadium integration for GrapheneOS. See https://github.com/GrapheneOS/Vanadium for the Vanadium build configuration and patches.
ochrona-cli - A command line tool for detecting vulnerabilities in Python dependencies and doing safe package installs
openvas-docker - A Docker container for Openvas
pip-audit - Audits Python environments, requirements files and dependency trees for known security vulnerabilities, and can automatically fix them
gokart-action - Integrate GoKart security static analysis to GitHub Actions
macOS-Security-and-Privacy-Guide - Guide to securing and improving privacy on macOS
fenix - Rust toolchains and rust-analyzer nightly for Nix [maintainer=@figsoda]
algo - Set up a personal VPN in the cloud