5 ms·

What IMHO really is needed are https://reproducible-builds.org/ https://reproducible-builds.org/ plus some way to verify within a company that only allowed pac

What IMHO really is needed are https://reproducible-builds.org/ https://reproducible-builds.org/ plus some way to verify within a company that only allowed packages are used. One way to solve this is to check all software (including open source one) into a monorepo and run software that checks for copies of open source code.

dathinab 6y ago
Reproducible build require source code access. Which is the first point I think is necessary: - Access to source code for at least all entities using the software (including allowing hiring entities to analyze it). Preferable open access to source. Even more preferable open source. - Combine that with reproducible builds and automatic code analysis and you gain additional trust. - Naturally this both requires proper code and artifact signing (which was compromised in the supply chain attack this article refers to). Funny thing is I'm 100% convinced no SBOM, reproducible builds or similar would have prevented this attack. It would just have changed how exactly the attack looks (IMHO). Still it would be an improvement anyway.
- jacques_chester 6y ago
  Reproducible builds would've had a sporting chance of defeating the solarwinds attack, because the injection point was on particular build servers that were reached through other vectors. If a second party performs a build to verify it, the attacker now has ~2x the cost to conceal their attack.
  - dathinab 6y ago
    True, but this requires the source you build not to have been gone through the build server, which is reasonable. The thing is you can circumvent this by attacking the version control and/or developer systems. And at least the later one are often massively vulnerable to certain kind of supply chain attacks. Ironically the permissions and setups commonly used for a nice development flow are also making systems vulnerable for many kinds of supply chain attacks. I'm currently slowly moving to a more secure dev flow, but it adds overhead. Especially if your dev system is also your laptop. First step is to run any kind of dev tool (especially builds) in a container. Through this often also means running e.g. a language server in the container while running your IDE out of it and making sure nothing will trigger your IDE to do thinks outside of the container...
    - jacques_chester 6y ago
      None of these solutions is complete, but that's not a final argument against them. Raising the cost of attack is always beneficial. It reduces the number of attackers and the number of attacks.

dathinab 6y ago

Reproducible build require source code access. Which is the first point I think is necessary: - Access to source code for at least all entities using the software (including allowing hiring entities to analyze it). Preferable open access to source. Even more preferable open source. - Combine that with reproducible builds and automatic code analysis and you gain additional trust. - Naturally this both requires proper code and artifact signing (which was compromised in the supply chain attack this article refers to). Funny thing is I'm 100% convinced no SBOM, reproducible builds or similar would have prevented this attack. It would just have changed how exactly the attack looks (IMHO). Still it would be an improvement anyway.

jacques_chester 6y ago
Reproducible builds would've had a sporting chance of defeating the solarwinds attack, because the injection point was on particular build servers that were reached through other vectors. If a second party performs a build to verify it, the attacker now has ~2x the cost to conceal their attack.
- dathinab 6y ago
  True, but this requires the source you build not to have been gone through the build server, which is reasonable. The thing is you can circumvent this by attacking the version control and/or developer systems. And at least the later one are often massively vulnerable to certain kind of supply chain attacks. Ironically the permissions and setups commonly used for a nice development flow are also making systems vulnerable for many kinds of supply chain attacks. I'm currently slowly moving to a more secure dev flow, but it adds overhead. Especially if your dev system is also your laptop. First step is to run any kind of dev tool (especially builds) in a container. Through this often also means running e.g. a language server in the container while running your IDE out of it and making sure nothing will trigger your IDE to do thinks outside of the container...
  - jacques_chester 6y ago
    None of these solutions is complete, but that's not a final argument against them. Raising the cost of attack is always beneficial. It reduces the number of attackers and the number of attacks.