Dependency Management #
Control ID: SDLC-CTRL-0004 | Type: Preventive
Summary #
Every dependency is defined securely, managed, and auditable as part of the software development lifecycle.
Mitigates Risk
Description #
Inputs to the build process — including third-party libraries, container base images, and other source code — can introduce security and quality issues. Dependencies must be explicitly defined, controlled, and transparent to maintain the integrity of the software supply chain.
During build, these inputs can be recorded as the software bill of materials alongside binary provenance, enabling traceability of all components included in a release.
Requirements #
- All dependencies MUST be explicitly defined in version-controlled dependency files (e.g.
go.mod,requirements.txt,package.json,Dockerfile) - Dependencies MUST comply with licensing requirements agreed by Kosli
- Lock files MUST be used to ensure reproducible builds and prevent silent dependency changes
- Dependencies SHOULD be recorded as a software bill of materials when recording binary provenance
- Container base images MUST be explicitly versioned and pinned
How we implement this control #
We define these dependencies in the source code, at the application level and if relevant, at the Docker image level.
| Application | Dependencies |
|---|---|
| CLI | Golang Dependencies |
| Server | Python Dependencies Docker Dependencies NPM Dependencies |
| Slack Application | Python Dependencies Docker Dependencies |
Compliance Frameworks #
NIST SP 800-53 Rev. 5
- SA-9 — External system services — third-party dependencies are external services/components that must be managed and controlled.
- SA-12 — Supply chain protection — dependency management controls the inputs to the build process.
- SA-22 — Unsupported system components — dependencies must be actively maintained and not end-of-life.
- CM-8 — System component inventory — all dependencies must be catalogued and traceable.
- SR-4 — Provenance — requires tracking the origin and integrity of software components.
- CM-7 — Least functionality — only necessary dependencies should be included.
SOC 2 Type II
- CC8.1 — Requires changes to be authorised and tested; dependency management ensures third-party components are explicitly declared and reviewed.
- PI1.3 — Requires processing integrity; pinned and verified dependencies prevent unexpected behaviour from upstream changes.
- CC7.2 — Requires monitoring of system components; maps to tracking dependency versions and known vulnerabilities.