5 ms·

At risk like node/npm with all the supply-chain attacks then? Or is there something that cargo does to manage it differently (due diligence?).

Jalad 10mo ago
Supply-chain attacks aren't really a property of the dependency management system Not having a dependency management system isn't a solution to supply chain attacks, auditing your dependencies is
- ashishb 10mo ago
  > auditing your dependencies is How do you do that practically? Do you read the source of every single package before doing a `brew update` or `npm update`? What if these sources include binary packages? The popular Javascript React framework has 15K direct and 2K indirect dependencies - https://deps.dev/npm/react/19.2.3 https://deps.dev/npm/react/19.2.3 Can anyone even review it in a month? And they publish a new update weekly.
  - nicoburns 10mo ago
    Normally it would omly be the diff from a previous version. But yes, it's not really practical for small companies or individuals atm. Larger companies do exactly this. We need better tooling to enable crowdsourcing and make it accessible for everyone.
    - ashishb 10mo ago
      > Larger companies do exactly this. Someone committed malicious code in Amazon Developer Q. AWS published a malicious version of their own extension. https://aws.amazon.com/security/security-bulletins/AWS-2025-015 https://aws.amazon.com/security/security-bulletins/AWS-2025-...
  - minitech 10mo ago
    > The popular Javascript React framework has 15K direct and 2K indirect dependencies - https://deps.dev/npm/react/19.2.3 https://deps.dev/npm/react/19.2.3 You’re looking at the number of dependents. The React package has no dependencies. Asides: > Do you read the source of every single package before doing a `brew update` or `npm update`? Yes, some combination of doing that or delegating it to trusted parties is required. (The difficulty should inform dependency choices.) > What if these sources include binary packages? Reproducible builds, or don’t use those packages.
    - ashishb 10mo ago
      > You’re looking at the number of dependents. The React package has no dependencies. Indeed. My apologies for misinterpreting the link that I posted. Consider "devDependencies" here https://github.com/facebook/react/blob/main/package.json https://github.com/facebook/react/blob/main/package.json As far as I know, these 100+ dev dependencies are installed by default. Yes, you can probably avoid it, but it will likely break something during the build process, and most people just stick to the default anyway. > Reproducible builds, or don’t use those packages. A lot of things are not reproducible/hermetic builds. Even GitHub Actions is not reproducible https://nesbitt.io/2025/12/06/github-actions-package-manager.html https://nesbitt.io/2025/12/06/github-actions-package-manager... Most frontend frameworks are not reproducible either. > don’t use those packages. And do what?
      - nicoburns 10mo ago
        > As far as I know, these 100+ dev dependencies are installed by default. devDependencies should only be installed if you're developing the React library itself. They won't be installed if you just depend on React.
        ashishb 10mo ago
        > They won't be installed if you just depend on React. Please correct me if I am wrong, here's my understanding. "npm install installs both dependencies and dev-dependencies unless NODE_ENV is set to production."
  - j1elo 10mo ago
    If that is really the case (I don't know numbers about React), in projects with a sane criteria of security, they would either only jump between versions that have passed a complete verification process (think industry certifications); or the other option is that simply by having such an enormous amount of dependencies would render that framework an undesirable tool to use, so they would just avoid it. What's not serious is living the life and incorporating 15-17K dependencies blindly because YOLO. (so yes, I'm stating that 99% of JS devs who _do_ precisely that, are not being serious, but at the same time I understand they just follow the "best practices" that the ecosystem pushes downstream, so it's understandable that most don't want to swim against the current when the whole ecosystem itself is not being serious either)
  - rcxdude 10mo ago
    More useful than reading the code, in most cases, is looking at who's behind the code. Can you identify the author? Do they have an identity and reputation in the space? Are you looking at the version of the package they manage? People often freak out about the number of packages in such ecosystems but what matters a lot more is how many different people are in your dependency tree, who they are, and how they operate. (The next most useful step, in the case where someone in your dependency tree is pwned, is to not have automated systems that update to the latest version frequently. Hang back a few days or so at least so that any damage can be contained. Cargo does not update to the latest version of a dependency on a built because of its lockfiles: you need to run an update manually)
    - deleted 10mo ago
      [deleted]
    - nicoburns 10mo ago
      > More useful than reading the code, in most cases, is looking at who's behind the code. Can you identify the author? Do they have an identity and reputation in the space? That doesn't necessarily help you in the case of supply chains attacks. A large proportion of them are spread through compromised credentials. So even if the author of a package is reputable, you may still get malware through that package.
  - QuiEgo 10mo ago
    In security-sensitive code, you take dependencies sparingly, audit them, and lock to the version you audited and then only take updates on a rigid schedule (with time for new audits baked in) or under emergency conditions only. Not all dependencies are created equal. A dependency with millions of users under active development with a corporate sponsor that has a posted policy with an SLA to respond to security issues is an example of a low-risk dependency. Someone's side project with only a few active users and no way to contact the author is an example of a high-risk dependency. A dependency that forces you to take lots of indirect dependencies would be a high-risk dependency. Here's an example dependency policy for something security critical: https://github.com/tock/tock/blob/master/doc/ExternalDependencies.md https://github.com/tock/tock/blob/master/doc/ExternalDepende... Practically, unless you code is super super security sensitive (something like a root of trust), you won't be able to review everything. You end up going for "good" dependencies that are lower risk. You throw automated fuzzing and linting tools, and these days ask AI to audit it as well. You always have to ask: what are the odds I do something dumb and introduce a security bug vs what are the odds I pull a dependency with a security bug. If there's already "battle hardened" code out there, it's usually lower risk to take the dep than do it yourself. This whole thing is not a science, you have to look at it case-by-case.
  - johncolanduoni 10mo ago
    The best tool for your median software-producing organization, who can’t just hire a team of engineers to do this, is update embargoes. You block updating packages until they’ve been on the registry for a month or whatever by default, allowing explicit exceptions if needed. It would protect you from all the major supply-chain attacks that have been caught in the wild. > The popular Javascript React framework has 15K direct and 2K indirect dependencies - https://deps.dev/npm/react/19.2.3 https://deps.dev/npm/react/19.2.3 You’re looking a dependents. The core React package has no dependencies.
  - goku12 10mo ago
    > How do you do that practically? Do you read the source of every single package before doing a `brew update` or `npm update`? There are several ways to do this. What you mentioned is the brute-force method of security audits. That may be impractical as you allude to. Perhaps there are tools designed to catch security bugs in the source code. While they will never be perfect, these tools should significantly reduce the manual effort required. Another obvious approach is to crowd source the verification. This can be achieved through security advisory databases like Rust's rustsec [1] service. Rust has tools that can use the data from rustsec to do the audit (cargo-audit). There's even a way to embed the dependency tree information in the target binary. Similar tools must exist for other languages too. > What if these sources include binary packages? Binaries can be audited if reproducible builds are enforced. Otherwise, it's an obvious supply chain risk. That's why distros and corporations prefer to build their software from source. [1] https://rustsec.org/ https://rustsec.org/
nicoburns 10mo ago
You can use "cargo vendor" to copy-paste your dependencies C-style if you want to, and audit them all if you want. Mozilla does this for Firefox. Cargo does have lock files by default. But we really need better tooling for auditing (and enforcing tha auditing has happened) to properly solve this.
- drnick1 10mo ago
  I think the broader point being made here is that the C-style approach is to extract a minimal subset of the dependency and tightly review it and integrate it into your code. The Rust/Python approach is to use cargo/pip and treat the dependency as a black box outside your project.
  - Cyph0n 10mo ago
    Advocates of the C approach often gloss over the increased maintenance burden, especially when it comes to security issues. In essence, you’re signing up to maintain a limited fork & watch for CVEs separately from upstream. So it's ultimately a trade off rather than a strictly superior solution. Also, nothing in Rust prevents you from doing the same thing. In fact, I would argue that Cargo makes this process easier.
    - ronjakoi 10mo ago
      But that's what Linux distros are for, package maintainers watch the CVEs for you, and all you have to do is "apt upgrade"
      - Cyph0n 10mo ago
        Not sure I follow. Suppose you tore out a portion of libxml2 for use in your HTTP server. A CVE is filed against libxml2 that is related to the subset you tore out. Obviously, your server doesn't link against libxml2. How exactly would distro maintainers know to include your package in their list?
        10mo ago
pxc 10mo ago
Edit: I misremembered a Rust crates capability (pre- and post-install hooks), so my comment was useless and misleading.
- steveklabnik 10mo ago
  Rust crates can run arbitrary code at build time: https://doc.rust-lang.org/cargo/reference/build-scripts.html https://doc.rust-lang.org/cargo/reference/build-scripts.html
  - pxc 10mo ago
    Geez, thank you.
  - rafram 10mo ago
    > Build scripts communicate with Cargo by printing to stdout. Oh lord.
    - ComputerGuru 10mo ago
      Wrote an entire crate to clean up that mess (and provide traditional autoconf-ish features for build.rs): https://crates.io/crates/rsconf https://crates.io/crates/rsconf
- nasso_dev 10mo ago
  Aren't procedural macros amd build.rs arbitrary code being executed at build time?
  - tuetuopay 10mo ago
    Pretty much, yes. And they don’t have much as far as isolation goes. It’s a bit frightening honestly. It does unlock some interesting things to be sure, like sqlx’ macros that check the query at compile time by connecting to the database and checking the query against it. If this sounds like the compiler connecting to a database, well, it’s because it is.
- 10mo ago
shatsky 10mo ago
I don't know much about node but cargo has lock file with hashes which prevents dep substitution unless dev decide to update lock file. Updating lock file has same risks as initial decision to depend on deps.

Jalad 10mo ago

Supply-chain attacks aren't really a property of the dependency management system Not having a dependency management system isn't a solution to supply chain attacks, auditing your dependencies is

ashishb 10mo ago
> auditing your dependencies is How do you do that practically? Do you read the source of every single package before doing a `brew update` or `npm update`? What if these sources include binary packages? The popular Javascript React framework has 15K direct and 2K indirect dependencies - https://deps.dev/npm/react/19.2.3 https://deps.dev/npm/react/19.2.3 Can anyone even review it in a month? And they publish a new update weekly.
- nicoburns 10mo ago
  Normally it would omly be the diff from a previous version. But yes, it's not really practical for small companies or individuals atm. Larger companies do exactly this. We need better tooling to enable crowdsourcing and make it accessible for everyone.
  - ashishb 10mo ago
    > Larger companies do exactly this. Someone committed malicious code in Amazon Developer Q. AWS published a malicious version of their own extension. https://aws.amazon.com/security/security-bulletins/AWS-2025-015 https://aws.amazon.com/security/security-bulletins/AWS-2025-...
- minitech 10mo ago
  > The popular Javascript React framework has 15K direct and 2K indirect dependencies - https://deps.dev/npm/react/19.2.3 https://deps.dev/npm/react/19.2.3 You’re looking at the number of dependents. The React package has no dependencies. Asides: > Do you read the source of every single package before doing a `brew update` or `npm update`? Yes, some combination of doing that or delegating it to trusted parties is required. (The difficulty should inform dependency choices.) > What if these sources include binary packages? Reproducible builds, or don’t use those packages.
  - ashishb 10mo ago
    > You’re looking at the number of dependents. The React package has no dependencies. Indeed. My apologies for misinterpreting the link that I posted. Consider "devDependencies" here https://github.com/facebook/react/blob/main/package.json https://github.com/facebook/react/blob/main/package.json As far as I know, these 100+ dev dependencies are installed by default. Yes, you can probably avoid it, but it will likely break something during the build process, and most people just stick to the default anyway. > Reproducible builds, or don’t use those packages. A lot of things are not reproducible/hermetic builds. Even GitHub Actions is not reproducible https://nesbitt.io/2025/12/06/github-actions-package-manager.html https://nesbitt.io/2025/12/06/github-actions-package-manager... Most frontend frameworks are not reproducible either. > don’t use those packages. And do what?
    - nicoburns 10mo ago
      > As far as I know, these 100+ dev dependencies are installed by default. devDependencies should only be installed if you're developing the React library itself. They won't be installed if you just depend on React.
      - ashishb 10mo ago
        > They won't be installed if you just depend on React. Please correct me if I am wrong, here's my understanding. "npm install installs both dependencies and dev-dependencies unless NODE_ENV is set to production."
- j1elo 10mo ago
  If that is really the case (I don't know numbers about React), in projects with a sane criteria of security, they would either only jump between versions that have passed a complete verification process (think industry certifications); or the other option is that simply by having such an enormous amount of dependencies would render that framework an undesirable tool to use, so they would just avoid it. What's not serious is living the life and incorporating 15-17K dependencies blindly because YOLO. (so yes, I'm stating that 99% of JS devs who _do_ precisely that, are not being serious, but at the same time I understand they just follow the "best practices" that the ecosystem pushes downstream, so it's understandable that most don't want to swim against the current when the whole ecosystem itself is not being serious either)
- rcxdude 10mo ago
  More useful than reading the code, in most cases, is looking at who's behind the code. Can you identify the author? Do they have an identity and reputation in the space? Are you looking at the version of the package they manage? People often freak out about the number of packages in such ecosystems but what matters a lot more is how many different people are in your dependency tree, who they are, and how they operate. (The next most useful step, in the case where someone in your dependency tree is pwned, is to not have automated systems that update to the latest version frequently. Hang back a few days or so at least so that any damage can be contained. Cargo does not update to the latest version of a dependency on a built because of its lockfiles: you need to run an update manually)
  - deleted 10mo ago
    [deleted]
  - nicoburns 10mo ago
    > More useful than reading the code, in most cases, is looking at who's behind the code. Can you identify the author? Do they have an identity and reputation in the space? That doesn't necessarily help you in the case of supply chains attacks. A large proportion of them are spread through compromised credentials. So even if the author of a package is reputable, you may still get malware through that package.
- QuiEgo 10mo ago
  In security-sensitive code, you take dependencies sparingly, audit them, and lock to the version you audited and then only take updates on a rigid schedule (with time for new audits baked in) or under emergency conditions only. Not all dependencies are created equal. A dependency with millions of users under active development with a corporate sponsor that has a posted policy with an SLA to respond to security issues is an example of a low-risk dependency. Someone's side project with only a few active users and no way to contact the author is an example of a high-risk dependency. A dependency that forces you to take lots of indirect dependencies would be a high-risk dependency. Here's an example dependency policy for something security critical: https://github.com/tock/tock/blob/master/doc/ExternalDependencies.md https://github.com/tock/tock/blob/master/doc/ExternalDepende... Practically, unless you code is super super security sensitive (something like a root of trust), you won't be able to review everything. You end up going for "good" dependencies that are lower risk. You throw automated fuzzing and linting tools, and these days ask AI to audit it as well. You always have to ask: what are the odds I do something dumb and introduce a security bug vs what are the odds I pull a dependency with a security bug. If there's already "battle hardened" code out there, it's usually lower risk to take the dep than do it yourself. This whole thing is not a science, you have to look at it case-by-case.
- johncolanduoni 10mo ago
  The best tool for your median software-producing organization, who can’t just hire a team of engineers to do this, is update embargoes. You block updating packages until they’ve been on the registry for a month or whatever by default, allowing explicit exceptions if needed. It would protect you from all the major supply-chain attacks that have been caught in the wild. > The popular Javascript React framework has 15K direct and 2K indirect dependencies - https://deps.dev/npm/react/19.2.3 https://deps.dev/npm/react/19.2.3 You’re looking a dependents. The core React package has no dependencies.
- goku12 10mo ago
  > How do you do that practically? Do you read the source of every single package before doing a `brew update` or `npm update`? There are several ways to do this. What you mentioned is the brute-force method of security audits. That may be impractical as you allude to. Perhaps there are tools designed to catch security bugs in the source code. While they will never be perfect, these tools should significantly reduce the manual effort required. Another obvious approach is to crowd source the verification. This can be achieved through security advisory databases like Rust's rustsec [1] service. Rust has tools that can use the data from rustsec to do the audit (cargo-audit). There's even a way to embed the dependency tree information in the target binary. Similar tools must exist for other languages too. > What if these sources include binary packages? Binaries can be audited if reproducible builds are enforced. Otherwise, it's an obvious supply chain risk. That's why distros and corporations prefer to build their software from source. [1] https://rustsec.org/ https://rustsec.org/

nicoburns 10mo ago

You can use "cargo vendor" to copy-paste your dependencies C-style if you want to, and audit them all if you want. Mozilla does this for Firefox. Cargo does have lock files by default. But we really need better tooling for auditing (and enforcing tha auditing has happened) to properly solve this.

drnick1 10mo ago
I think the broader point being made here is that the C-style approach is to extract a minimal subset of the dependency and tightly review it and integrate it into your code. The Rust/Python approach is to use cargo/pip and treat the dependency as a black box outside your project.
- Cyph0n 10mo ago
  Advocates of the C approach often gloss over the increased maintenance burden, especially when it comes to security issues. In essence, you’re signing up to maintain a limited fork & watch for CVEs separately from upstream. So it's ultimately a trade off rather than a strictly superior solution. Also, nothing in Rust prevents you from doing the same thing. In fact, I would argue that Cargo makes this process easier.
  - ronjakoi 10mo ago
    But that's what Linux distros are for, package maintainers watch the CVEs for you, and all you have to do is "apt upgrade"
    - Cyph0n 10mo ago
      Not sure I follow. Suppose you tore out a portion of libxml2 for use in your HTTP server. A CVE is filed against libxml2 that is related to the subset you tore out. Obviously, your server doesn't link against libxml2. How exactly would distro maintainers know to include your package in their list?
      - 10mo ago

pxc 10mo ago

Edit: I misremembered a Rust crates capability (pre- and post-install hooks), so my comment was useless and misleading.

steveklabnik 10mo ago
Rust crates can run arbitrary code at build time: https://doc.rust-lang.org/cargo/reference/build-scripts.html https://doc.rust-lang.org/cargo/reference/build-scripts.html
- pxc 10mo ago
  Geez, thank you.
- rafram 10mo ago
  > Build scripts communicate with Cargo by printing to stdout. Oh lord.
  - ComputerGuru 10mo ago
    Wrote an entire crate to clean up that mess (and provide traditional autoconf-ish features for build.rs): https://crates.io/crates/rsconf https://crates.io/crates/rsconf
nasso_dev 10mo ago
Aren't procedural macros amd build.rs arbitrary code being executed at build time?
- tuetuopay 10mo ago
  Pretty much, yes. And they don’t have much as far as isolation goes. It’s a bit frightening honestly. It does unlock some interesting things to be sure, like sqlx’ macros that check the query at compile time by connecting to the database and checking the query against it. If this sounds like the compiler connecting to a database, well, it’s because it is.
10mo ago

shatsky 10mo ago

I don't know much about node but cargo has lock file with hashes which prevents dep substitution unless dev decide to update lock file. Updating lock file has same risks as initial decision to depend on deps.