An internal registry should log who or what requested each package, the exact name and version, the time, the source address, whether it was served from cache or fetched upstream, and any rule that blocked or allowed it. Keep logs long enough to answer a question about last year's build.
Why the log matters
When a package is reported as malicious, the first question is who downloaded it. Without logs the answer is a guess, and you must treat every machine as possibly affected. With logs, you can name the build jobs and laptops and focus your response.
A registry is also a single place to see unusual behavior, such as a pipeline suddenly pulling many new packages.
Fields to capture
| Field | Why |
|---|---|
| Timestamp | Orders events and sets exposure windows |
| Authenticated identity | User or service account, not only an IP address |
| Source address or runner name | Locates the machine |
| Ecosystem, package and exact version | Matches against advisories |
| Artifact checksum | Proves which file was served |
| Result | Served from cache, fetched upstream, blocked, or not found |
| Rule or policy matched | Explains a block or an allow |
| Client tool and version | Spots odd clients and old tools |
Make identities meaningful. Shared tokens used by dozens of pipelines make logs far less useful, so give each pipeline or team its own credential.
Retention
Set retention to the longest period you may need to investigate. For many organizations that is at least a year. Store logs in a place the registry administrators cannot silently edit, and test that you can search them.
Alerts worth building
- A package or version on your blocklist is requested.
- A request for a name very similar to an internal package, which can indicate a confusion attempt.
- A first ever download of a package from a build job with access to production secrets.
- A sudden jump in new packages from one identity.
- Many failed authentication attempts against the registry.
- A new upstream source added to the registry configuration.
Start with two or three alerts and tune them. An alert nobody reads is noise.
Respond with the log
When a flagged package appears, search by name and version, list identities, check whether the install ran code, rotate secrets reachable from affected machines and rebuild clean. Keep the query you used with the incident record.
Quick check
Is the proxy log enough without SBOMs?
They answer different questions. The log shows what was downloaded. SBOMs show what ended up in each product. Use both.
Do logs contain personal data?
They can, since they hold user identities and addresses. Apply your retention and access rules to them.
Safeguard scans dependencies and builds SBOMs, runs reachability analysis, and applies policies and gates on pull requests, so the rules in this post can be checked automatically. Autonomous fix PRs are off by default, with every category on Manual. You can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
