Best practices for dependency management

This text describes a set of finest practices for managing dependencies of your software, together with vulnerability monitoring, artifact verification, and steps to cut back your dependency footprint and make it reproducible.

The specifics of every of those practices might range relying on the specifics of your language ecosystem and the tooling you utilize, however basic rules apply.

Dependency administration is just one facet of making a safe and dependable software program provide chain. For details about different finest practices, see the next sources:

• Finest practices for constructing containers
• Shifting left on safety
• Provide chain Ranges for Software program Artifacts (SLSA)
• DevOps capabilities from DevOps Analysis & Evaluation

Model pinning

Briefly, model pinning means limiting the model of a dependency of your software to a really particular model—ideally, a single model.

Pinning variations on your dependencies has a facet impact of freezing your software in time. Whereas that is good observe for reproducibility, it has the draw back of stopping you from receiving updates because the dependency makes new releases, both for safety fixes, bug fixes, or basic enhancements.

This may be mitigated by making use of automated dependency administration instruments to your supply management repositories. These instruments monitor your dependencies for brand spanking new releases, and make updates to your necessities information to improve you to these new releases as essential, usually together with changelog info or extra particulars.

Signature and hash verification

To make sure that a given artifact for a given launch of a package deal is definitely what you plan to put in, there are a variety of strategies that mean you can confirm the authenticity of the artifact with various ranges of safety.

Hash verification lets you examine the hash of a given artifact with a recognized hash offered by the artifact repository. Enabling hash verification ensures that your dependencies can’t be surreptitiously changed by totally different information, both by a man-in-the-middle assault or a compromise of the artifact repository. This requires trusting that the hash you obtain from the artifact repository on the time of verification (or on the time of first retrieval) is just not compromised as properly.

Signature verification provides extra safety to the verification course of. Artifacts could also be signed by the artifact repository, by the maintainers of the software program, or each. New companies like sigstore search to make it simple for maintainers to signal software program artifacts and for shoppers to confirm these signatures.

Lockfiles and compiled dependencies

Lockfiles are totally resolved necessities information, specifying precisely what model of a dependency ought to be put in for an software. Normally produced mechanically by set up instruments, lockfiles mix model pinning and signature or hash verification with a full dependency tree on your software.

Full dependency timber are produced by ‘compiling’ or totally resolving all dependencies that can be put in on your top-level dependencies. A full dependency tree implies that all dependencies of your software, together with all sub-dependencies, their dependencies, and onwards down the stack, are included in your lockfile. It additionally implies that solely these dependencies may be put in, so builds may be thought of extra reproducible and constant between a number of installs. 

Mixing personal and public dependencies

Trendy cloud-native functions usually depend upon each open supply, third-party code, in addition to closed-source, inside libraries. The latter may be particularly helpful if you want to share what you are promoting logic throughout a number of functions, and once you wish to reuse the identical tooling to put in each exterior and inside libraries, utilizing personal repositories like Artifact Registry make it simple.

Nevertheless, when mixing personal and public dependencies, concentrate on the “dependency confusion” assault: by publishing tasks with the identical identify as your inside challenge to open-source repositories, attackers might be able to benefit from misconfigured installers to surreptitiously set up their malicious libraries over your inside package deal.

To keep away from a “dependency confusion” assault, you possibly can take plenty of steps:

• Confirm the signature or hashes of your dependencies by together with them in a lockfile
• Separate the set up of third-party dependencies and inside dependencies into two distinct steps
• Explicitly mirror the third-party dependencies you want into your personal repository, both manually or with a pull-through proxy

Eradicating unused dependencies

Refactoring occurs: generally a dependency you want someday is not essential the subsequent day. Persevering with to put in dependencies alongside along with your software after they’re not getting used will increase your dependency footprint in addition to the potential so that you can be compromised by a vulnerability in these dependencies.

A typical observe is to get your software working domestically, copy each dependency you put in through the growth course of into the necessities file on your software, after which deploy that. It’s assured to work, however it’s additionally prone to introduce dependencies you don’t want in manufacturing.

Usually, be cautious when including new dependencies to your software: every one has the potential to introduce extra code that you just don’t have full management over. Utilizing instruments to audit your necessities information to find out in case your dependencies are literally getting used or imported lets you combine this into your common linting and testing pipeline.

Vulnerability scanning

How will you be notified if a vulnerability is recognized in one in all your dependencies? Chances are high, you aren’t actively monitoring all vulnerability databases for the third-party software program you depend upon, and probably you could not be capable to reliably audit what third-party software program you depend upon in any respect.

Vulnerability scanning lets you mechanically and persistently assess whether or not your dependencies are introducing vulnerabilities into your software. Vulnerability scanning instruments devour lockfiles to find out precisely what artifacts you depend upon, and notify you when new vulnerabilities floor, generally even with urged improve paths.

Instruments like Container Evaluation can present a wide selection of vulnerability scanning for container photographs, in addition to language artifacts like Java package deal scanning. When enabled, this function identifies package deal vulnerabilities in your container photographs. Pictures are scanned when they’re uploaded to Artifact Registry and the information is constantly monitored to seek out new vulnerabilities for as much as 30 days after pushing the picture.