4 ms·

I’ve mentioned this before, but at my previous employer we set up staged Artifactory so tha production couldn’t pull from anything that hadn’t been through the

I’ve mentioned this before, but at my previous employer we set up staged Artifactory so tha production couldn’t pull from anything that hadn’t been through the test stage, and test couldn’t pull from anything that hadn’t been through CI. Because releases were relatively slow (weekly) compared to other places I worked (continuous), we had a reasonable lead time to have third party packages scanned for vulns before they made it to production. The setup was very minimal, really just a script to link one stage’s artifacts to the next stage’s repo. But the end effect was production never pulled from the internet and never pulled packages that hadn’t been deployed to the previous stage.

giancarlostoro 8mo ago
Reminds me of my favorite setup for a React project. We had rotating deployed builds (like three or more of them) for pull requests, the React UI pointed to a specific system so you always had consistent data, devs would immediately be able to test the UI, QA could follow immediately after.
skeeter2020 8mo ago
>> But the end effect was production never pulled from the internet Having production ever pull from the interwebs just seems bonkers to me. Even if you (for some reason?) want to stay up-to-date on every single dependency release you should be pulling to your own repo with some sort of gated workflow. If you're doing continuous deployment you definitely want to put extra control around your external dependencies, and releasing your product quickly after they change is probably the rare exception.
- vova_hn2 8mo ago
  > Having production ever pull from the interwebs just seems bonkers to me. Is it really that big of an issue if your package manager pins dependencies by hash? I guess, public package registry can be down an brake your pipeline, that's a risk. But I don't see how it introduces any new security problems.
  - rlpb 8mo ago
    Pinning dependencies by hash is completely undermined by automation that then updates the pins without meaningful review, as is common.
    - vova_hn2 8mo ago
      I think that this is the issue then, not pulling dependencies from the internet directly. > meaningful review No that I think about it, maybe for the first time in history it's actually feasible to review all the code in the repos using LLMs. Before LLMs were a thing, for any big project that would be way too much work to realistically do it. Also, someone can provide code review of publicly available dependencies as a service, to avoid wasting tokens of reviewing same code again and again by each dev locally on their machine. U wonder if anyone is already working on such service...
      - zvr 8mo ago
        Most (all?) of the solutions offered are not providing a "code review service" but rather a "curated registry" one: download from us and we guarantee some things. It's definitely more widely known/used for container images than individual software packages.
- actionfromafar 8mo ago
  You can still lock versions, or even hashes. But it still leaves you open to "denial of service" if the "interwebs" acts up or someone unpublishes a package.
canpan 8mo ago
Something similar is easy with docker. Build the image when releasing to your first stage env, deploy the very same image to the next stage, until it reaches production. Nothing can break in between and enough time to test.
zvr 8mo ago
The complexity (and therefore the effort) of implementing such a setup varies greatly, depending on the ecosystem you're working on: Java, Python, Rust, Go, Node, ...

giancarlostoro 8mo ago

Reminds me of my favorite setup for a React project. We had rotating deployed builds (like three or more of them) for pull requests, the React UI pointed to a specific system so you always had consistent data, devs would immediately be able to test the UI, QA could follow immediately after.

skeeter2020 8mo ago

>> But the end effect was production never pulled from the internet Having production ever pull from the interwebs just seems bonkers to me. Even if you (for some reason?) want to stay up-to-date on every single dependency release you should be pulling to your own repo with some sort of gated workflow. If you're doing continuous deployment you definitely want to put extra control around your external dependencies, and releasing your product quickly after they change is probably the rare exception.

vova_hn2 8mo ago
> Having production ever pull from the interwebs just seems bonkers to me. Is it really that big of an issue if your package manager pins dependencies by hash? I guess, public package registry can be down an brake your pipeline, that's a risk. But I don't see how it introduces any new security problems.
- rlpb 8mo ago
  Pinning dependencies by hash is completely undermined by automation that then updates the pins without meaningful review, as is common.
  - vova_hn2 8mo ago
    I think that this is the issue then, not pulling dependencies from the internet directly. > meaningful review No that I think about it, maybe for the first time in history it's actually feasible to review all the code in the repos using LLMs. Before LLMs were a thing, for any big project that would be way too much work to realistically do it. Also, someone can provide code review of publicly available dependencies as a service, to avoid wasting tokens of reviewing same code again and again by each dev locally on their machine. U wonder if anyone is already working on such service...
    - zvr 8mo ago
      Most (all?) of the solutions offered are not providing a "code review service" but rather a "curated registry" one: download from us and we guarantee some things. It's definitely more widely known/used for container images than individual software packages.
actionfromafar 8mo ago
You can still lock versions, or even hashes. But it still leaves you open to "denial of service" if the "interwebs" acts up or someone unpublishes a package.

canpan 8mo ago

Something similar is easy with docker. Build the image when releasing to your first stage env, deploy the very same image to the next stage, until it reaches production. Nothing can break in between and enough time to test.

zvr 8mo ago

The complexity (and therefore the effort) of implementing such a setup varies greatly, depending on the ecosystem you're working on: Java, Python, Rust, Go, Node, ...