SEC11-BP05 Centralize services for packages and dependencies
Provide centralized services for builder teams to obtain software packages and other dependencies. This allows the validation of packages before they are included in the software that you write, and provides a source of data for the analysis of the software being used in your organization.
Desired outcome: Software is comprised of a set of other software packages in addition to the code that is being written. This makes it simple to consume implementations of functionality that are repeatedly used, such as a JSON parser or an encryption library. Logically centralizing the sources for these packages and dependencies provides a mechanism for security teams to validate the properties of the packages before they are used. This approach also reduces the risk of an unexpected issue being caused by a change in an existing package, or by builder teams including arbitrary packages directly from the internet. Use this approach in conjunction with the manual and automated testing flows to increase the confidence in the quality of the software that is being developed.
Common anti-patterns:
-
Pulling packages from arbitrary repositories on the internet.
-
Not testing new packages before making them available to builders.
Benefits of establishing this best practice:
-
Better understanding of what packages are being used in the software being built.
-
Being able to notify workload teams when a package needs to be updated based on the understanding of who is using what.
-
Reducing the risk of a package with issues being included in your software.
Level of risk exposed if this best practice is not established: Medium
Implementation guidance
Provide centralized services for packages and dependencies in a
way that is simple for builders to consume. Centralized services
can be logically central rather than implemented as a monolithic
system. This approach allows you to provide services in a way that
meets the needs of your builders. You should implement an
efficient way of adding packages to the repository when updates
happen or new requirements emerge. AWS services such as
AWS CodeArtifact
Implementation steps:
Implement a logically centralized repository service that is available in all of the environments where software is developed.
Include access to the repository as part of the AWS account vending process.
Build automation to test packages before they are published in a repository.
Maintain metrics of the most commonly used packages, languages, and teams with the highest amount of change.
-
Provide an automated mechanism for builder teams to request new packages and provide feedback.
-
Regularly scan packages in your repository to identify the potential impact of newly discovered issues.
Resources
Related best practices:
Related documents:
Related videos:
Related examples: