Nexus Repository Best Practices: Cleanup Policies, Part 2

Sonatype Nexus Repository Best Practices
, , , ,
1

In our last Best Practices post (which you can read here) we talked a little about cleanup policies. The operative word there is “little” – there’s a lot more to say.

This one may be obvious, but a best practice is to store build artifacts and binaries inside Nexus Repository. Development is messy, relentless, and complicated. Having a central place to store build artifacts is a major step towards DevSecOps. There are lots of repositories you can use for this purpose…but we’re biased, so we say Nexus Repository is best.

Another best practice is to store your SBOMs inside Nexus Repository, also. In fact, it’s generally wise to treat your SBOMs like build artifacts. Why? SBOMs are a point-in-time accounting of your app’s contents, in much the same way a manifest or lock file is a point-in-time declaration. They’re a build artifact in all but name.

But doing these things make controlling your blob storage even trickier. Build artifacts are naturally bulky. And though SBOMs are more lightweight, they’ll pile up fast, especially if you’re generating SBOMs with every build (and you should be).

So how do you use cleanup policies to address this? There’s no simple, one-sentence answer here, but we can offer some advice.

  • Snapshots pile up fast, and you typically only need n-1 or n-2 versions. Find the build cadence of your snapshots and set the cleanup policy for slightly longer than that.
  • SBOMs for snapshots, development, or test builds are low-importance. Again, set the cleanup policy for slightly longer than the build cadence.
  • Release candidates are different. You need the ability to rollback to n-2, n-3 or farther. Find the build cadence of your release candidates, quadruple it, and set the cleanup policy for slightly longer than that. Don’t try to fine-tune that cleanup policy until you’re confident you can rollback.
  • SBOMs for release candidates are important. Again, they’re a point-in-time accounting of your app’s contents. Default to keeping release candidate SBOMs for a long time. Consider moving them to cold storage rather than deleting them.

And, though it goes without saying, the last best practice is to adhere to regulatory requirements, common sense, and your company’s guidelines when it comes to keeping SBOMs and release candidates.

Next time, we’ll talk about how to combine staging with cleanup policies and put a bow on this whole process with the blobstore.compact task.

Resources:

Nexus Repository Administration Best Practices

Cleanup Policies

Staging Concepts

Storage Planning

2

i would like to know if you suggest to store SBOM’s alongside the application artifacts, or in a separate repository.

1 Like
3

Hi, Ingmar! Sorry for the delayed reply. That’s a very good question.

The arguments for storing your SBOMs separately from artifacts are:

  • SBOMs are not called, used, or distributed in the same way as artifacts
  • Easier access controls: the people who need access to artifacts aren’t identical to the people who need access to SBOMs

But the argument for storing SBOMS alongside artifacts are:

  • Makes security reviews easier
  • Makes scanning with Lifecycle simpler
  • Adds context to your SBOMs
  • Potentially easier to configure with your CI/CD process

To answer your question: in the ideal scenario, you’d keep a copy of the SBOM alongside the artifacts, with another copy in a separate repository for distribution to vendors, regulatory purposes, etc. But it really all depends on what your organization is doing with SBOMs.

1 Like