Be conservative in your software choices. If your software stack relies on a few off-the-shelf Debian packages and nothing more, you are pretty safe.
Ask HN: Pragmatic way to avoid supply chain attacks as a developer
11–20 of 23 posts
Re: Ask HN: Pragmatic way to avoid supply chain attacks as a developer
#12I've found an effective band-aid is 'become the supply chain'. Running your own cache, poorly, has advantages. You don't get the latest silliness by forgetting to update sometimes.
Re: Ask HN: Pragmatic way to avoid supply chain attacks as a developer
#13A defense-in-depth approach with a special eye to compartmentalization/separation/sandboxing coupled with principle-of-least privilege is a good stance to take, I think. Also keep in mind that "security is a process, not a product". There is no silver bullet no tool will save you from yourself...
With this in mind:
- https://qubes-os.org - Use separate VMs for separate domains. Use disposable VMs for temporary sessions.
- https://github.com/legobeat/l7-devenv - My project. Separate containers for IDE and (ephemeral) code-under-test. Transparent access to just the directories needed and nothing else, without compromising on performance and productivity. Separation of authentication token while transparent to your scripts and dev-tools. Editor add-ons are pinned via submodules and baked into the image at build-time (and easy to update on a rebuild). Feedback very welcome!
- In general, immutable distros like Fedora Silverblue and MicroOS (whatever happened to SUSE ALP?) also worth considering, to limit persistence. Couples well with a setup like the one I linked above.
- Since you seem to be in a Node.js context, I should also mention @lavamoat/allow-scripts (also affiliated via $work) as something you can consider to reel in your devDeps: https://github.com/LavaMoat/LavaMoat/tree/main/packages/allo...
Re: Ask HN: Pragmatic way to avoid supply chain attacks as a developer
#14I see the people posting here suggesting isolation for development. While this is a good model, doesn't it suffer from the risk that you are not using the same isolation set up in production, for whatever reason?
In that sense, isolation for develop to solve supply chain security seems a symptom-treater not a cause-treater.
A more extreme approach is to:
minimize dependencies, built a lot in-house, don't update pre-vetted dependencies before another audit
In general, I think a big dependency chain is useful for getting to PoC quickly (and in some cases it's indeed unavoidable, eg. numpy etc), but in building many simplish web apps and client server applications it's feasible to have a very narrow dependency chain, especially back-end. You can even do this front-end if you eschew framework stuff.
Re: Ask HN: Pragmatic way to avoid supply chain attacks as a developer
#15A large portion of my role at $DayJob is around improving supply chain security. Some examples of how we do it: - Devs can only use hardened (by us) Docker images hosted inside our infrastructure. Policies enforce this during CI and runtime on clusters. - All Maven/PIP/NodeJS/etc. dependencies are pulled through via proxy and scanned before first use. All future CI jobs pull from this internal cache. - Only a handful…
> All Maven/PIP/NodeJS/etc. dependencies are pulled through via proxy and scanned before first use.
What does the scanning process check for / which tools are used?
Re: Ask HN: Pragmatic way to avoid supply chain attacks as a developer
#16A large portion of my role at $DayJob is around improving supply chain security. Some examples of how we do it: - Devs can only use hardened (by us) Docker images hosted inside our infrastructure. Policies enforce this during CI and runtime on clusters. - All Maven/PIP/NodeJS/etc. dependencies are pulled through via proxy and scanned before first use. All future CI jobs pull from this internal cache. - Only a handful…
Sounds like you’re running a tight ship – congrats!
Have you received feedback from your dev teams on the ergonomics of the setup?
Re: Ask HN: Pragmatic way to avoid supply chain attacks as a developer
#17I've found an effective band-aid is 'become the supply chain' . Running your own cache, poorly, has advantages. You don't get the latest silliness by forgetting to update sometimes.
This could perhaps be done in a structured way - e.g. a pip cache/proxy with a configurable update availability delay.
Re: Ask HN: Pragmatic way to avoid supply chain attacks as a developer
#18There are really only a handful of approaches to preventing this kind of supply chain attack, and all come with tradeoffs (ranging from the infeasible to the merely impractical):
- Don't take any 3rd party dependencies. Build everything in house instead. Likely only possible in niche areas of government/defence where sky-high budgets intersect with intense scrutiny.
- Manually validate each new version of every dependency in your tree. Also very expensive, complex vulnerabilities will likely still slip through (i.e. things like SPECTRE aren't going to be caught in code review).
- Use firewalls/network security groups/VPC-equivalents to prevent any network traffic that isn't specifically related to the correct operation of your software. Increasingly hard to enforce, as our tech stacks rely on more and more SaaS offerings. Needs a properly staffed network admin to enforce and reduce the pain points on developers.
- Network isolated VMs/containers that can only talk to a dedicated container that handles all network traffic. Imposes odd constraints on software architecture, doesn't play well with SaaS dependencies.
In practice you run with whatever combination of the above you can afford, and hope for the best.
Re: Ask HN: Pragmatic way to avoid supply chain attacks as a developer
#19A large portion of my role at $DayJob is around improving supply chain security. Some examples of how we do it: - Devs can only use hardened (by us) Docker images hosted inside our infrastructure. Policies enforce this during CI and runtime on clusters. - All Maven/PIP/NodeJS/etc. dependencies are pulled through via proxy and scanned before first use. All future CI jobs pull from this internal cache. - Only a handful…
That's great advice, thanks! What are you using to scan the packages/images if I may ask?
Re: Ask HN: Pragmatic way to avoid supply chain attacks as a developer
#20I've found an effective band-aid is 'become the supply chain' . Running your own cache, poorly, has advantages. You don't get the latest silliness by forgetting to update sometimes.
This could perhaps be done in a structured way - e.g. a pip cache/proxy with a configurable update availability delay.
Definitely! I suggest that where possible. Some implementations require creativity, where others it's a mundane configurable option.
It's not necessarily as easy as timely snapshots. For example, not knowing when the upstream may be syncing. Signatures, release interdependence, etc.
There is intent in my framing, however. Once the cache is made... do or don't mind the cadence - the benefit is there for the moment. Performance/availability :)
This is really just a central actor to other procedures. Scanning, eviction, and so on.