4 ms·

I believe one thing that can help security a little is to use full version numbers in your dependency list. This applies to all package managers. Because the m

by tdrdt 5y ago

I believe one thing that can help security a little is to use full version numbers in your dependency list. This applies to all package managers. Because the moment someone hits update on the package manager nothing will get updated and you won't receive potential dangerous updates you did not review first. Edit: sorry this is not relevant to the question...

richardwhiuk 5y ago
You want to have a file specifying your dependencies, and a file specifying your currently locked set - e.g. Cargo.toml and Cargo.lock, or Gemfile and Gemfile.lock, or pyproject.toml and poetry.lock You'll then want tooling to periodically update your locked dependencies, so that you pick up fixes to security vulnerabilties. That wants to go through your CI.
- deleted 5y ago
  [deleted]
- tompazourek 5y ago
  This is a double edged sword. Because on one hand, you do pick up hotfix patches, but on the other hand, you are possibly bit more exposed to supply chain attacks. Any ideas on how to balance that out? Or should we just not consider supply chain attacks to be a real threat?
  - richardwhiuk 5y ago
    Mirror the upstream, and as part of mirroring, do an automated security analysis of your dependencies. Sandbox your dependencies. Run automated security vulnerability testing on your program, looking for rogue behaviour. Require code signatures on dependencies. Identity security critical components and audit them.
tailspin2019 5y ago
> sorry this is not relevant to the question... It’s a very good tip though. I must start doing this.
2OEH8eoCRo0 5y ago
Full version numbers, pin your dependencies, commit dependencies to a local repo. Update them only when necessary (security patch, feature you need).
- WA 5y ago
  Can you elaborate? Your local repo then re-exports the dependencies to be consumed by your application or how would you do it properly?

by tdrdt 5y ago

richardwhiuk 5y ago

You want to have a file specifying your dependencies, and a file specifying your currently locked set - e.g. Cargo.toml and Cargo.lock, or Gemfile and Gemfile.lock, or pyproject.toml and poetry.lock You'll then want tooling to periodically update your locked dependencies, so that you pick up fixes to security vulnerabilties. That wants to go through your CI.

deleted 5y ago
[deleted]
tompazourek 5y ago
This is a double edged sword. Because on one hand, you do pick up hotfix patches, but on the other hand, you are possibly bit more exposed to supply chain attacks. Any ideas on how to balance that out? Or should we just not consider supply chain attacks to be a real threat?
- richardwhiuk 5y ago
  Mirror the upstream, and as part of mirroring, do an automated security analysis of your dependencies. Sandbox your dependencies. Run automated security vulnerability testing on your program, looking for rogue behaviour. Require code signatures on dependencies. Identity security critical components and audit them.

tailspin2019 5y ago

> sorry this is not relevant to the question... It’s a very good tip though. I must start doing this.

2OEH8eoCRo0 5y ago

Full version numbers, pin your dependencies, commit dependencies to a local repo. Update them only when necessary (security patch, feature you need).

WA 5y ago
Can you elaborate? Your local repo then re-exports the dependencies to be consumed by your application or how would you do it properly?