Module 9 Lesson 2: Dependency & License Compliance

Your code is only 10% of your app. The other 90% is the thousands of libraries you download from NPM, PyPI, or Maven. This is your Software Supply Chain.

1. Dependency Scanning

This scan looks at your "Lock files" (e.g., package-lock.json or requirements.txt).

• It compares your versions against the CVE (Common Vulnerabilities and Exposures) database.
• The Alert: "You are using Lodash 4.1.0, which has an Out-of-bounds Read vulnerability. Please update to 4.1.1."

---

2. License Compliance

This isn't about security; it's about Legal Risk.

• Some open-source licenses (like GPL) might force you to make your private business code "Open Source" if you use them!
• GitLab can automatically flag any library that uses a "Forbidden" license.

---

3. Creating a Policy

You can set a policy:

• Allowed: MIT, Apache, BSD.
• Denied: AGPL, No-License.
• Review Needed: Every other license.

---

4. The SBOM (Software Bill of Materials)

Modern regulations (like in the US and Europe) now require companies to provide an SBOM—a complete "List of Ingredients" for their software.

• GitLab can generate this JSON or CycloneDX file for you automatically as part of your pipeline.

---

Exercise: The Ingredient Check

1. Look at a random package-lock.json file. Estimate how many "Child" libraries are in there.
2. In your GitLab project, add the Dependency-Scanning.gitlab-ci.yml template.
3. Why might a "License Violation" be more expensive for a company than a "Small Security Bug"?
4. Research: What is a "Supply Chain Attack"? How did the "Log4j" incident change how we think about dependencies?

---

Summary

Dependency Scanning turns your pipeline into a "Health Inspector" for your libraries. By auditing the quality and the legality of your supply chain, you protect your company from both hackers and lawyers.

Next Lesson: Policy as Code: Compliance Pipelines.