In the S2C2F's Ingest practice, why keep your own copy of every OSS package you consume?

## What Ingest actually asks for The S2C2F's Ingest practice says that open source you consume is pulled through, and retained in, something your organisation owns - rather than being resolved from a public index at the moment a build runs. It is easy to mis-hear this as a performance measure. It is not a cache for build speed; the speed is a side effect. It is the practice that turns consumption into an event you have a record of. ## The three properties a copy buys **The artifact still exists.** Upstream releases are not immutable facts. A version can be yanked, deleted, or republished with different content under the same version string, and maintainers do all three for entirely legitimate reasons. Without your own copy you lose three abilities at once: to rebuild what you shipped, to re-scan the exact bytes when an advisory lands months later, and to hand an investigator the file you actually consumed rather than a name and a number. **There is somewhere to attach a control.** Scan, Enforce, Inventory and Audit are all defined relative to a boundary. Ingest is that boundary. This is the part candidates usually under-state: without a chokepoint, "we enforce a policy on open source" describes the path taken by people who already agreed with the policy. **Identity becomes content, not a label.** A name and a version are what an index says today. A digest is what you have. Once inventory keys on the file you hold, questions like "is this the same artifact two services consumed" have an answer that does not depend on anyone's registry. ## What it does not buy Ingesting does not vet. A copied malicious package is a malicious package you now host, with the added indignity that you have made it conveniently available internally. Ingest is a **prerequisite** for the practices that judge - it is not one of them. The framework's own layering says the same thing: retaining copies sits at the level about reducing remediation time, while enforcing an ingestion policy and hunting malicious content sit a level above. ## The decision it forces Here is the uncomfortable part. Every property above holds only if the internal copy is the **only** thing that resolves. If a developer can fall back to the public index when something is missing, you have a copy of most of what you consume and a chokepoint that covers most builds, and "most" is not a property you can build an audit answer on. So the practice forces a platform decision with real friction attached, and that friction is why it is a maturity step rather than a configuration change. Make that concrete. A bank runs a data-science platform: roughly three hundred analysts and researchers work in hosted notebooks, each able to pull arbitrary packages, and the assets at stake are the firm's models and research rather than customer records. The attacker position that matters here is not an anonymous outsider - it is an authenticated, low-privilege tenant of the platform, or code arriving inside a package one of them installs, running with that tenant's access to model code and training data. Making an internal store the only resolvable source is what gives the platform team any answer at all to "which notebooks installed this package, and when". The friction is equally real: a researcher who wants a library published an hour ago now waits, and the platform team owns an exception path forever. ## The hole nobody scores In exactly that environment, the ingest boundary usually leaks somewhere it is not being measured. Model weights, datasets and files fetched by a line of code inside a notebook are dependencies in every practical sense - they are third-party content that ends up inside what runs - but they do not resolve through a package manager, so they cross no chokepoint and appear in no inventory. A team can score the Ingest practice green on the strength of its package handling while a large share of what it actually consumes never touches it. ## The standing costs Retention grows without bound unless someone owns a policy for it. Storage is the cheap part; the expensive parts are deciding how long consumed artifacts must be kept to be useful for later triage, capturing licence and origin metadata at ingest time because it is far harder to reconstruct afterwards, and staffing the exception path. Those costs are the honest answer to "why has this not been done already", and being able to name them is what separates a middle-level answer from a recited one.