3 ms·

look at diffs?

by cerved 5y ago

look at diffs?

apetresc 5y ago
Can you really say, with a straight face, that you inspect the diffs of your entire dependency closure every time you deploy an update? With the level of scrutiny required to detect a maliciously-obfuscated security exploit? If you can, you're an infinitely more diligent developer than I am, that's for sure.
- dane-pgp 5y ago
  Fortunately the problem could become more tractable if something like SES / Endo takes off: "Endo protects program integrity both in-process and in distributed systems. SES protects local integrity, defending an application against supply chain attacks: hacks that enter through upgrades to third-party dependencies. Endo does this by encouraging the Principle of Least Authority. ... Endo uses LavaMoat to automatically generate reviewable policies that determine what capabilities will be distributed to third party dependencies." https://github.com/endojs/endo https://github.com/endojs/endo
  - naasking 5y ago
    Nice link, thanks! Good to see Mark Miller is still working in this space.
- cerved 5y ago
  I look at gits diffs to see what's changed between versions, but that's for fun and not diligence. > With the level of scrutiny required to detect a maliciously-obfuscated security exploit Nope. Not paid to do that and I have not been given any such responsibility. That said, I think the attack vector on this is very low. Packages are rarely updated to the latest version. We don't use a lot of packages. We mostly use packages from trusted sources. We use packages that are open source.
- rich_sasha 5y ago
  And frankly, not just diffs. You’d need to inspect the initial state, and any new dependency added. That’s potentially hundreds of thousands of LoC.
deathanatos 5y ago
I actually do this, on occasion. (Not 100%, and not to a degree I'd say "yeah, I'd've caught this colors/fakers thing." But enough to say that I've seen a decent sample.) There is literally, on average, no difference in average quality between commits on FOSS projects, and commits on projects we pay external entities for. Some paid projects are just crap code, and some FOSS code is extremely high quality. I've had to roll-back / hard-pin dependencies from both low-quality FOSS & low-quality paid projects because of commits that — once you find & read them — are just bananas. (I have no idea how to solve the root problem here, honestly.)
- cerved 5y ago
  > I have no idea how to solve the root problem here I'm not even sure what the problem is. If it's "updating dependencies introduces severe side effects" wich, I think, should be accounted for in the process

look at diffs?

by cerved 5y ago

look at diffs?

Can you really say, with a straight face, that you inspect the diffs of your entire dependency closure every time you deploy an update? With the level of scrutiny required to detect a maliciously-obfuscated security exploit? If you can, you're an infinitely more diligent developer than I am, that's for sure.

dane-pgp 5y ago
Fortunately the problem could become more tractable if something like SES / Endo takes off: "Endo protects program integrity both in-process and in distributed systems. SES protects local integrity, defending an application against supply chain attacks: hacks that enter through upgrades to third-party dependencies. Endo does this by encouraging the Principle of Least Authority. ... Endo uses LavaMoat to automatically generate reviewable policies that determine what capabilities will be distributed to third party dependencies." https://github.com/endojs/endo https://github.com/endojs/endo
- naasking 5y ago
  Nice link, thanks! Good to see Mark Miller is still working in this space.
cerved 5y ago
I look at gits diffs to see what's changed between versions, but that's for fun and not diligence. > With the level of scrutiny required to detect a maliciously-obfuscated security exploit Nope. Not paid to do that and I have not been given any such responsibility. That said, I think the attack vector on this is very low. Packages are rarely updated to the latest version. We don't use a lot of packages. We mostly use packages from trusted sources. We use packages that are open source.
rich_sasha 5y ago
And frankly, not just diffs. You’d need to inspect the initial state, and any new dependency added. That’s potentially hundreds of thousands of LoC.

deathanatos 5y ago

I actually do this, on occasion. (Not 100%, and not to a degree I'd say "yeah, I'd've caught this colors/fakers thing." But enough to say that I've seen a decent sample.) There is literally, on average, no difference in average quality between commits on FOSS projects, and commits on projects we pay external entities for. Some paid projects are just crap code, and some FOSS code is extremely high quality. I've had to roll-back / hard-pin dependencies from both low-quality FOSS & low-quality paid projects because of commits that — once you find & read them — are just bananas. (I have no idea how to solve the root problem here, honestly.)

cerved 5y ago
> I have no idea how to solve the root problem here I'm not even sure what the problem is. If it's "updating dependencies introduces severe side effects" wich, I think, should be accounted for in the process