Security, Ethics and Software Supply-Chain Governance

Introduction

Version control is often treated as a productivity tool, but a Git repository is also a security boundary, an intellectual-property record, and a distribution point for software. A compromised account can alter source code, rewrite history, expose credentials, or publish malicious releases. A vulnerable dependency can enter a project through an apparently harmless pull request. An incorrectly licensed file can create legal and commercial risk even when the code functions correctly.

Modern software governance therefore extends beyond protecting a server. It involves people, processes, repository configuration, authentication, code review, dependency management, release integrity, legal compliance, privacy, and incident response. GitHub and similar platforms provide controls such as protected branches, signed commits, secret scanning, dependency review, Dependabot, code scanning, security policies, and audit logs. These controls are valuable only when they are correctly configured and embedded in an effective governance system.

This chapter develops a practical and conceptual foundation for securing Git-based development. It also examines ethical responsibilities, open-source licensing, responsible disclosure, and software supply-chain frameworks.

Learning Objectives

By the end of this chapter, you should be able to:

• explain why source repositories are security and governance assets;
• protect important branches and tags using appropriate rules;
• apply least privilege, strong authentication, and separation of duties;
• distinguish commit signing, code review, and build provenance;
• use secret scanning, dependency review, Dependabot, and code scanning appropriately;
• interpret software bills of materials and supply-chain frameworks;
• evaluate licensing, attribution, privacy, and responsible disclosure obligations;
• design a proportionate repository-security policy; and
• analyse a software supply-chain incident and recommend controls.

1. The Repository as a Security Boundary

A repository contains more than source files. It may contain configuration, deployment manifests, infrastructure definitions, tests, documentation, issue discussions, release tags, credentials accidentally committed in the past, and evidence of who approved changes. Consequently, repository security has three related objectives:

1. Confidentiality: preventing unauthorised access to private code, credentials, personal data, and security reports.
2. Integrity: ensuring that code, history, tags, releases, and build inputs are not altered without authorisation.
3. Availability: ensuring that authorised developers can obtain and build the correct source when needed.

These objectives must be complemented by authenticity—confidence about the identity associated with an action—and provenance—evidence describing where software came from and how it was built.

A useful distinction is between a vulnerability in project code and a weakness in the development system. For example, SQL injection is a code vulnerability. An over-privileged deployment token, an unreviewed workflow change, or an unprotected release tag is a process or supply-chain weakness. Both can produce a security incident.

Threats to Git-based development

Common threats include:

• credential theft and account takeover;
• malicious pull requests or compromised maintainer accounts;
• force-pushing over reviewed history;
• alteration of release tags or build workflows;
• dependency confusion, typosquatting, and compromised packages;
• malicious or vulnerable transitive dependencies;
• leaked API keys, tokens, certificates, or passwords;
• tampered CI runners or build artifacts; and
• insider misuse or accidental disclosure.

Security is therefore a risk-management activity rather than a single product feature. Controls should be selected according to asset value, threat likelihood, potential impact, and operational cost.

2. Identity, Least Privilege and Separation of Duties

Authentication and authorisation

Authentication establishes who a user or service is. Authorisation determines what that identity may do. A developer may be authenticated successfully but still lack permission to merge into a production branch. Confusing these concepts leads to excessive access.

Recommended foundations include:

• multi-factor authentication, preferably using phishing-resistant security keys or passkeys for privileged users;
• centralised organisation accounts and prompt removal of departing users;
• short-lived, narrowly scoped tokens instead of persistent personal access tokens;
• separate identities for human users and automation;
• protected organisation and repository settings; and
• periodic access reviews supported by audit logs.

Least privilege

Least privilege means granting only the permissions necessary for a defined task, for only as long as they are needed. A deployment workflow that only uploads an artifact should not receive permission to delete repositories or modify organisation membership. A contributor who submits documentation should not automatically receive write access to release configuration.

Least privilege applies at several levels:

Separation of duties reduces the chance that one compromised or dishonest identity can introduce and release harmful code. For a high-risk production system, one person may author a change, another approve it, and an automated process build and deploy it. Small teams may not achieve complete separation, but they should document compensating controls such as mandatory review, signed releases, and independent monitoring.

3. Protecting Branches, Tags and Workflows

A branch is a movable reference, whereas a tag is normally used to identify a significant point such as a release. Both are references that can be manipulated if permissions are too broad.

Branch protection

Important branches such as main, release/*, and production branches should normally require:

• pull requests rather than direct pushes;
• at least one or more suitable approvals;
• successful automated tests and security checks;
• resolution of review conversations;
• current branch status before merging, where appropriate;
• restrictions on who may push or bypass rules;
• prevention of force-push and deletion; and
• an explicit policy for emergency changes.

A review is not merely a formality. Reviewers should examine the purpose of the change, security-sensitive files, dependency changes, workflow permissions, tests, and unexpected generated files. CODEOWNERS-style rules can require subject-matter experts to review selected paths, but ownership files themselves must be protected because changing them can change who reviews future code.

Tag and release protection

Release tags should be protected against unauthorised creation, deletion, and movement. A mutable tag can cause users to download different source while believing they are obtaining the same version. Release processes should define:

1. who may create a release;
2. how version numbers are selected;
3. how the source is built;
4. how artifacts are signed or otherwise associated with provenance;
5. how vulnerabilities are assessed; and
6. how a compromised release is revoked or replaced.

A signed tag or signed commit provides cryptographic evidence that a particular key made the signature, assuming the key was properly controlled. It does not prove that the code is safe, that the signer reviewed every line, or that the key itself was not compromised. Signing is therefore complementary to review, testing, access control, and reproducible or attestable builds.

Workflow security

CI workflow files can execute with powerful permissions. Treat changes to workflow definitions as security-sensitive. Use pinned action versions where practical, review third-party actions, minimise the workflow token's permissions, avoid printing secrets, and restrict deployment jobs to protected environments requiring approval. Secrets should not be exposed to untrusted pull-request code, particularly for contributions originating outside the trusted repository.

4. Commit Signing, Auditability and Evidence

Git records author and committer fields, but these fields alone are not proof of identity; they can be manually entered. Commit signing uses cryptographic keys to provide stronger evidence that a key-holder approved a commit. Common mechanisms include SSH-based signing and OpenPGP-based signing, depending on platform and organisational policy.

Signing supports:

• detection of commits altered after signing;
• association of commits with a controlled identity;
• stronger release and audit evidence; and
• policies requiring verified contributions.

Limitations remain important. A valid signature may have been created by malware controlling the developer's workstation. It does not establish that the commit passed review or that dependencies are trustworthy. Organisations should protect signing keys, provide revocation procedures, use hardware-backed keys for high-value identities where feasible, and explain how lost or compromised keys are handled.

Audit logs should record administrative changes, authentication events, permission changes, workflow activity, and security-alert actions. Logs should be protected from unauthorised alteration and retained according to legal, operational, and privacy requirements.

5. Detecting Secrets and Vulnerabilities

Secret scanning

Secret scanning searches commits, pull requests, issues, and sometimes historical data for patterns associated with credentials. Advanced systems may use provider verification to determine whether a detected token is active. Detection is not remediation. When a secret is exposed, the first response is generally to revoke or rotate it, investigate use, remove it from future history where appropriate, and assess whether sensitive data was accessed.

Removing a secret from the latest file does not make the old value safe: it may remain in Git history, forks, caches, logs, artifacts, or clone directories. History rewriting can reduce exposure but does not replace rotation. Prevention mechanisms, such as push protection, can stop many accidental disclosures before they enter the repository.

False positives and false negatives are possible. Teams should define ownership, response time, suppression rules, and escalation paths. Suppressions should be justified and reviewed rather than used to silence inconvenient alerts.

Dependency review and Dependabot

A dependency review compares proposed dependency changes with the current dependency graph. It can identify version changes, known vulnerabilities, licence changes, and potentially risky additions before merge. It is especially useful in pull requests because it places analysis at the decision point.

Dependabot-like services can identify outdated or vulnerable dependencies and create update pull requests. Automated updates reduce maintenance delay but do not eliminate risk. Updates should be tested, grouped carefully, and reviewed for breaking changes, malicious packages, licence effects, and transitive dependencies. A project should distinguish:

• direct dependencies, explicitly declared by the project;
• transitive dependencies, installed because another dependency requires them;
• development dependencies, used for building or testing; and
• runtime dependencies, present in the deployed application.

A vulnerability's severity is not the same as its project risk. Risk depends on exploitability, exposure, affected functionality, compensating controls, and whether the vulnerable component is actually reachable. Teams should document prioritisation and exceptions rather than relying on a severity number alone.

Code scanning

Static application security testing, commonly called SAST, analyses source or intermediate code for patterns associated with vulnerabilities. It can detect some injection risks, insecure APIs, weak cryptography, and data-flow problems. It cannot prove the absence of vulnerabilities and may generate false positives. Code scanning is strongest when combined with secure design review, unit and integration tests, dynamic testing, dependency analysis, and manual investigation.

Security alerts should have an owner, severity-based service targets, a documented disposition, and a process for accepting residual risk. Closing an alert without evidence is not remediation.

6. Software Supply-Chain Governance

A software supply chain includes developers, source repositories, package registries, dependencies, build systems, CI runners, signing services, deployment platforms, and users. A compromise at any stage can affect downstream consumers.

A layered supply-chain model

A practical model has five layers:

1. Source: identity, review, branch rules, and repository integrity.
2. Dependencies: provenance, vulnerability status, licence, and version control.
3. Build: isolated runners, controlled tools, reproducibility, and attestations.
4. Release: protected tags, artifact integrity, signing, and traceability.
5. Operation: monitoring, vulnerability response, rollback, and communication.

A control at one layer cannot compensate completely for failure at another. For example, a signed artifact may faithfully authenticate a malicious build if the build environment was compromised.

SBOMs and provenance

A software bill of materials (SBOM) is a structured inventory of components in a software product. It can support vulnerability response, licence analysis, and supplier transparency. Common SBOM formats include SPDX and CycloneDX. An SBOM is useful only when it is accurate, current, associated with the correct artifact, and protected against tampering.

Build provenance describes how an artifact was produced: source revision, builder, inputs, timestamps, parameters, and relevant approvals. Frameworks and practices such as SLSA (Supply-chain Levels for Software Artifacts) organise increasing levels of assurance around source, build, and provenance. The exact requirements depend on the adopted version and implementation; organisations should avoid treating a framework level as a guarantee of safety.

Governance frameworks

Several frameworks are complementary rather than interchangeable:

• NIST Cybersecurity Framework organises cybersecurity activities around Govern, Identify, Protect, Detect, Respond, and Recover.
• NIST Secure Software Development Framework (SSDF) provides practices for preparing organisations, protecting software, producing well-secured software, and responding to vulnerabilities.
• SLSA focuses particularly on supply-chain integrity and provenance assurance.
• OWASP guidance supplies practical application-security knowledge and testing approaches.
• ISO/IEC 27001 provides an information-security management-system approach, including risk, controls, evidence, and continual improvement.

A governance program should select controls based on business context and demonstrate evidence: policy records, review history, access reviews, alert handling, release attestations, and incident exercises.

7. Licensing, Attribution and Intellectual Property

Open-source software is not the same as software without conditions. A licence grants permissions subject to requirements and restrictions. Important licence families include permissive licences such as MIT, BSD, and Apache 2.0, and reciprocal or copyleft licences such as GPL and AGPL. The exact legal effect depends on the licence text, distribution model, linking or combination method, and applicable law.

Teams should maintain a component inventory and preserve required copyright notices, licence texts, and attribution. They should not copy code merely because it is publicly visible. A dependency's licence may also impose obligations on distribution, source availability, patent rights, or network use.

Licence compliance is a governance process:

1. identify every included component and version;
2. record its licence and obligations;
3. evaluate compatibility with the intended product and distribution;
4. include notices and source offers where required; and
5. obtain legal review for ambiguous or high-impact cases.

Automated licence scanners are valuable but imperfect. They may misidentify licences, miss vendored code, or fail to understand modifications. Human review remains necessary.

8. Privacy and Responsible Disclosure

Repositories and security tools can process personal data, including names, email addresses, IP addresses, access logs, issue discussions, and accidentally committed customer information. Organisations should collect only necessary data, restrict access, define retention periods, protect exports, and comply with applicable privacy law and contractual obligations. Security monitoring does not create unlimited permission to inspect private employee data.

Responsible vulnerability disclosure

A mature project publishes a security policy containing:

• a supported contact channel;
• affected versions and security expectations;
• preferred reporting format;
• encryption instructions where appropriate;
• acknowledgement and response targets;
• coordinated disclosure principles; and
• safe-harbour language reviewed by appropriate experts.

Reporters should avoid accessing data beyond what is needed to demonstrate the issue, avoid service disruption, and allow reasonable time for remediation. Maintainers should acknowledge reports, assess severity, communicate realistically, credit reporters when permitted, release fixes or mitigations, and coordinate public disclosure. Retaliation against good-faith researchers undermines security and may discourage future reporting.

9. Ethical Decision-Making in Repository Governance

Security decisions involve competing values. A mandatory review may slow urgent delivery; extensive logging may improve accountability but increase privacy concerns; aggressive dependency updates may reduce known vulnerabilities but introduce incompatibilities.

A defensible decision process asks:

• Who could be harmed if this control is absent?
• Who bears the cost or surveillance burden of the control?
• Is the control proportionate to the risk?
• Is the decision transparent and reviewable?
• Does it respect privacy, accessibility, and legitimate research?
• What evidence supports the claimed benefit?

Ethical practice rejects security theatre. Requiring signatures without protecting keys, generating SBOMs that omit generated components, or closing alerts without analysis creates an appearance of control without dependable protection. Governance should focus on measurable assurance and honest communication.

10. An Applied Case: The Compromised Release Workflow

The following is an illustrative case.

Background

Northstar Analytics maintains a public data-processing library. Its source is hosted on GitHub, and releases are built automatically when a version tag is pushed. The repository contains a production deployment workflow and several third-party CI actions.

Problem

An engineer's personal access token is stolen through a malicious browser extension. The token has write access to the repository and permission to modify workflows. The attacker changes the release workflow, adds a step that uploads environment variables, and pushes a new release tag. The malicious release is downloaded by several customers before detection.

Analysis

The immediate cause is token compromise, but the incident reflects multiple governance weaknesses:

• the token was long-lived and over-privileged;
• release tags were not protected;
• workflow changes did not require specialised review;
• the release process did not require an independent approval;
• secrets were available to a broad workflow context;
• artifact provenance was incomplete; and
• monitoring did not alert on unusual tag creation or workflow modification.

Commit signing alone would not necessarily have prevented the incident if the attacker used the engineer's authenticated credentials or signing capability.

Approach and solution

Northstar revokes the token, rotates exposed credentials, blocks the malicious release, and notifies affected users. It preserves logs for investigation and reports the incident according to contractual obligations. The organisation then:

1. replaces persistent tokens with short-lived, narrowly scoped credentials;
2. protects release branches and tags;
3. requires review by a code owner for workflow changes;
4. separates build, approval, and deployment permissions;
5. restricts secrets to protected environments;
6. pins and reviews third-party actions;
7. generates an SBOM and provenance record for each release;
8. signs release artifacts using a protected release identity; and
9. monitors unusual administrative, workflow, and release events.

Outcome

Future releases require a reviewed pull request, passing security checks, an approved protected environment, and a controlled release action. Customers can verify the release artifact and consult the incident advisory. The organisation also conducts periodic exercises to test token revocation and release rollback.

Learning points

The case demonstrates defence in depth. Authentication, branch protection, workflow isolation, release governance, provenance, monitoring, and response each address different failure modes. No individual control is sufficient.

11. Implementation Guidance and Limitations

A practical adoption sequence is:

1. classify repositories by sensitivity and production impact;
2. enable MFA and review organisation membership;
3. protect default, release, and deployment branches;
4. remove unnecessary tokens and secrets, then enable push protection;
5. establish dependency and code-scanning workflows;
6. publish a security policy and vulnerability contact;
7. define licence and SBOM requirements;
8. protect workflows and deployment environments;
9. introduce signing and provenance in proportion to release risk; and
10. measure, audit, and improve the controls.

Important limitations include tool coverage, language support, configuration errors, alert fatigue, false confidence in automated analysis, dependency availability, and the difficulty of proving complete provenance in complex build systems. Controls also have operational costs. A small educational project may need a lighter process than a medical device platform, but both should understand the same principles.

Artificial intelligence can assist with code review, vulnerability triage, dependency explanation, and policy checks. However, AI-generated code may contain insecure patterns or incompatible licences, and AI tools may receive confidential source or prompts. Organisations should define data-handling rules, require human review for security decisions, and avoid treating generated explanations as evidence of correctness.

Chapter Summary

Git repositories are security, intellectual-property, and operational assets. Effective governance protects confidentiality, integrity, availability, authenticity, and provenance. Least privilege, MFA, separation of duties, branch protection, protected tags, workflow restrictions, and audit logs establish foundational control.

Signed commits and tags strengthen identity evidence but do not prove that code is safe or reviewed. Secret scanning requires rapid revocation and rotation, while dependency review and Dependabot support informed maintenance rather than automatic trust. Code scanning is useful but must be combined with testing and human analysis.

Software supply-chain governance covers source, dependencies, builds, releases, and operations. SBOMs, provenance, SLSA-oriented practices, NIST SSDF, NIST CSF, ISO/IEC 27001, and OWASP guidance provide complementary structures. Licensing requires inventory, attribution, compatibility analysis, and legal judgement. Privacy and responsible disclosure require proportionate data handling, clear reporting channels, and good-faith cooperation. Finally, governance is ethical when it is proportionate, transparent, evidence-based, and honest about residual risk.

Key Terms

Repository security: Protection of source, history, configuration, identities, and repository operations.

Least privilege: Granting only the access necessary for a defined task and period.

Separation of duties: Dividing responsibilities so one actor cannot independently perform all high-risk actions.

Branch protection: Rules restricting changes, review, merging, deletion, or force-pushing on selected branches.

Protected tag: A tag subject to restrictions on creation, modification, or deletion.

Commit signing: Cryptographic signing that provides evidence associated with a signing key.

Secret scanning: Detection of exposed credentials and other sensitive tokens.

Dependency review: Examination of dependency changes for security, licensing, and operational effects.

Transitive dependency: A component installed because another dependency requires it.

Code scanning: Automated analysis of source or related code for potential defects or vulnerabilities.

SBOM: Software bill of materials listing components included in a software product.

Provenance: Evidence about a software artifact’s source, inputs, builder, and production process.

SLSA: A framework for improving software supply-chain integrity and build provenance.

Vulnerability disclosure: The process of reporting, remediating, and communicating security weaknesses.

Attribution: Credit and notices required by a licence or ethical practice.

Copyleft: Licensing approach that may require derivative or distributed works to preserve specified freedoms or conditions.

Security policy: Documented rules and procedures governing protection, reporting, and response.

Residual risk: Risk remaining after controls have been implemented.

Review Questions

Short Answer Questions

1. Why is a Git repository considered a security boundary?
2. What is the difference between authentication and authorisation?
3. Why does rotating a leaked secret matter even after the secret is removed from a file?
4. What information can an SBOM provide?
5. Why does a valid commit signature not prove that code is secure?

Long Answer Questions

1. Explain how branch protection, code review, protected tags, and workflow restrictions work together to protect a release process.
2. Compare secret scanning, dependency review, Dependabot, and code scanning, including the limitations of each.
3. Describe how least privilege and separation of duties should be applied to a CI/CD system.
4. Discuss the role of licensing, attribution, and component inventories in responsible software development.
5. Explain how NIST SSDF, NIST CSF, SLSA, and SBOM practices can complement one another.

Analytical / Application Questions

1. A contributor adds a new package and modifies a deployment workflow in one pull request. Design a review and control process for evaluating the change.
2. A project discovers that a database password was committed six months ago and appears in several forks. Analyse the immediate response and the longer-term governance improvements required.
3. A small team argues that signed commits alone make protected branches unnecessary. Evaluate this claim and recommend a proportionate security architecture.

Multiple Choice Questions with Answers

Question 1

Which control most directly prevents unauthorised direct pushes to a production branch?

A. A protected branch requiring pull requests

B. A project README

C. A dependency lockfile

D. A local editor extension

Correct Answer: A. A protected branch requiring pull requests

Question 2

What is the primary purpose of least privilege?

A. To give every developer administrator access temporarily

B. To grant only the access necessary for a defined task

C. To eliminate the need for authentication

D. To ensure all repositories are public

Correct Answer: B. To grant only the access necessary for a defined task

Question 3

What should generally happen first when an active API token is discovered in repository history?

A. Rename the source file

B. Add a comment explaining the token

C. Revoke or rotate the token

D. Create a new branch

Correct Answer: C. Revoke or rotate the token

Question 4

Which statement about a signed commit is correct?

A. It proves the code contains no vulnerabilities

B. It proves every dependency was reviewed

C. It provides cryptographic evidence associated with a signing key

D. It prevents all future changes to the branch

Correct Answer: C. It provides cryptographic evidence associated with a signing key

Question 5

What is a transitive dependency?

A. A dependency installed because another dependency requires it

B. A dependency used only by a human reviewer

C. A dependency that has no version

D. A dependency stored outside all registries

Correct Answer: A. A dependency installed because another dependency requires it

Question 6

What is the main function of an SBOM?

A. To list the components included in a software product

B. To replace all security testing

C. To grant repository administrator rights

D. To encrypt source code automatically

Correct Answer: A. To list the components included in a software product

Question 7

Why should workflow files receive careful review?

A. They are only documentation files

B. They can execute with powerful permissions and access secrets

C. They cannot affect releases

D. They are never changed after repository creation

Correct Answer: B. They can execute with powerful permissions and access secrets

Question 8

Which practice best supports responsible vulnerability disclosure?

A. Publishing exploit details immediately without contacting maintainers

B. Providing a clear security contact and coordinating remediation

C. Ignoring reports from external researchers

D. Requesting unnecessary personal data from reporters

Correct Answer: B. Providing a clear security contact and coordinating remediation

Question 9

Which framework is particularly associated with secure software development practices?

A. NIST SSDF

B. HTML

C. DNS

D. JPEG

Correct Answer: A. NIST SSDF

Question 10

Why are automated licence scanners insufficient by themselves?

A. Licences never create obligations

B. They may misidentify licences or miss context requiring human judgement

C. They only operate on binary files

D. They automatically resolve all legal disputes

Correct Answer: B. They may misidentify licences or miss context requiring human judgement