Security, Ethics, and Governance

Introduction

Git and related version-control systems are often treated as developer productivity tools. In professional DevOps, however, a repository is also a security boundary, an evidence store, a record of authorship, and a control point for software supply-chain risk. Source code may reveal passwords, encryption keys, customer information, internal architecture, proprietary algorithms, or vulnerabilities. A commit history may also be required to demonstrate who approved a change, when it was introduced, and whether organisational controls were followed.

Security, ethics, and governance therefore extend beyond choosing a private repository. They include protecting credentials, limiting access, enforcing review, verifying authorship, detecting secrets, controlling dependencies, retaining appropriate records, and responding responsibly when mistakes occur. These practices support confidentiality, integrity, and availability while also promoting accountability and professional trust.

This chapter presents a practical governance model suitable for certificate-level DevOps work. It focuses on controls that can be implemented in common Git hosting platforms and integrated into continuous integration and continuous delivery (CI/CD) pipelines.

Learning Objectives

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

• distinguish source-code security, repository governance, and professional ethics;
• apply least-privilege access and protected-branch policies;
• explain the purpose of signed commits and verified authorship;
• prevent and respond to credential and sensitive-data exposure;
• use secret scanning and dependency controls appropriately;
• design practical retention and audit-trail policies;
• evaluate ethical questions involving authorship, attribution, automation, and artificial intelligence;
• apply these principles to a realistic DevOps case.

1. The Repository as a Governed Asset

A repository contains more than current files. It commonly contains branches, tags, pull requests, issue discussions, build definitions, release artefacts, deployment credentials, and an immutable or semi-immutable history. Each element can have security and governance implications.

Three properties are especially important:

• Confidentiality: only authorised people and systems can view protected information.
• Integrity: code, configuration, and history are not altered without authorisation or detection.
• Availability: authorised users can access the repository and required historical versions when needed.

Governance converts these goals into rules, responsibilities, and evidence. A governance policy should answer questions such as:

1. Who may read, write, approve, merge, or administer a repository?
2. Which branches may receive direct pushes?
3. What review and testing are required before release?
4. How are credentials issued, rotated, and revoked?
5. Which records must be retained, for how long, and why?
6. How are incidents reported and investigated?

Security controls should be proportionate to risk. A public documentation repository and a repository containing payment-processing software should not necessarily have identical controls, but both require deliberate ownership and clear accountability.

2. Least Privilege and Identity Management

Least privilege means granting each person, service, or automation process only the permissions necessary for its approved task, for only as long as necessary. It is not the same as giving everyone read-only access. A build system may need to read source code and publish a test result but have no authority to delete repositories or alter branch rules.

2.1 Roles and permissions

Typical repository permissions include:

Access should normally be assigned through groups or teams rather than individually. Group-based access makes joiner, mover, and leaver processes more reliable. When an employee changes role, their group membership can be reviewed rather than searching for numerous individual grants.

Strong identity controls include multi-factor authentication, single sign-on where appropriate, unique user accounts, periodic access reviews, and rapid removal of access when employment or project participation ends. Shared accounts weaken accountability because actions cannot reliably be attributed to one individual.

2.2 Human and machine identities

Automation should use dedicated service identities rather than personal access tokens. A deployment identity should be limited to the environments and actions required by its job. For example, a test job may receive a token that can download dependencies but cannot deploy production code.

Credentials should be stored in an approved secret manager or protected CI/CD variable facility, not in source files, issue comments, shell history, or unencrypted configuration. Tokens should have an expiry date and should be rotated. Rotation is not a substitute for least privilege: a long-lived token with narrow permissions may still create unacceptable risk.

3. Protected Branches and Change Control

A protected branch is a branch subject to technical rules that reduce unauthorised or unreviewed changes. The default or main branch is commonly protected, while release branches may have additional restrictions.

Useful protection rules include:

• prohibit direct pushes except for narrowly defined emergency roles;
• require pull or merge requests;
• require approval from at least one qualified reviewer;
• require successful automated tests and security checks;
• require current branch status before merging;
• prevent force-pushing and branch deletion;
• require conversations to be resolved;
• separate the person who writes code from the person who approves it for high-risk changes.

These controls implement separation of duties. They do not guarantee that a change is safe. Reviewers can overlook defects, tests can be incomplete, and an administrator may be able to bypass protection. Consequently, branch protection should be combined with logging, alerting, periodic review, and emergency procedures.

A practical pull-request policy should identify the evidence expected from a change: purpose, scope, test results, security impact, deployment considerations, and rollback plan. Small, focused changes are generally easier to review than large mixed-purpose commits.

4. Signed Commits and Authorship Integrity

A signed commit provides cryptographic evidence that a particular key was used to create or approve an object. Depending on the platform and signing method, a signature may verify that the commit was signed by a key associated with a known account. It does not prove that the code is correct, that the signer personally wrote every line, or that the signing key was not compromised.

Git can use OpenPGP or SSH-based signing, among other mechanisms supported by hosting platforms. A robust policy should clarify:

• which signing methods are accepted;
• how public keys are registered and verified;
• how keys are protected and rotated;
• how lost or compromised keys are revoked;
• whether signatures are required for all commits or only protected branches and releases.

Signed commits are most valuable when combined with protected branches and review records. A signed malicious commit is still malicious; signing improves provenance, not the quality of the content.

Authorship also has an ethical dimension. A developer should not claim sole authorship of code generated by another person, copied from a restricted source, or produced substantially by an AI system. Contributions should be attributed according to organisational policy and licence requirements. Commit identity should not be rewritten to conceal responsibility or evade an audit, except where an approved privacy or data-remediation process explicitly permits it.

5. Secrets and Sensitive Data

A secret is information whose disclosure could enable unauthorised access or harm. Examples include passwords, API keys, private certificates, signing keys, database connection strings, OAuth tokens, and cloud credentials. Sensitive data may also include personal data, health information, payment information, confidential business records, and security findings.

The safest secret is one that is never placed in Git. A .gitignore entry can prevent some accidental additions, but it is not a security control by itself: files may be force-added, copied under another name, or committed before the ignore rule exists. Likewise, deleting a file in a later commit does not necessarily remove it from repository history, forks, caches, or clones.

5.1 Prevention and detection

Effective prevention combines:

• secret managers and environment injection;
• pre-commit hooks for rapid local feedback;
• server-side secret scanning;
• CI checks that block suspicious changes;
• restricted access to logs and build artefacts;
• safe examples using placeholders rather than realistic credentials;
• developer education and incident rehearsals.

Secret-scanning tools use patterns, entropy analysis, provider-specific detectors, or combinations of these methods. They can produce false positives and can miss novel formats. A passing scan therefore does not prove that a repository is free of secrets.

5.2 Response to exposure

If a credential is committed, the first priority is revocation or rotation. Merely rewriting history is insufficient because the credential may already have been copied. A response should normally:

1. identify the credential and affected systems;
2. revoke, disable, or rotate it;
3. preserve appropriate evidence without spreading the secret further;
4. assess access logs and possible misuse;
5. remove the secret from active branches and, where justified, history and hosted caches;
6. notify responsible security and privacy personnel;
7. document the cause and corrective actions.

History rewriting can disrupt clones and references, so it should be coordinated. It is an additional containment measure, not the primary response.

6. Dependency and Supply-Chain Controls

Modern applications depend on libraries, packages, container images, build plugins, and actions maintained by other parties. A dependency may introduce a vulnerability, malicious code, licence conflict, abandoned maintenance, or unexpected transitive dependency.

A basic dependency-control programme includes:

• declaring dependencies in version-controlled manifests;
• using lockfiles where the ecosystem supports them;
• reviewing update provenance and release integrity;
• scanning direct and transitive dependencies for known vulnerabilities;
• generating a software bill of materials (SBOM) where appropriate;
• updating dependencies through reviewable pull requests;
• removing unused packages;
• restricting package sources and validating checksums or signatures where supported.

Pinning a dependency to an exact version improves reproducibility, but it can delay security updates. A balanced approach combines reproducible builds with an explicit update process and risk-based exceptions. Vulnerability scanners are decision-support tools, not automatic proof of exploitability or safety. Teams should consider reachability, affected features, exposure, compensating controls, and vendor information.

CI/CD actions and plugins require the same scrutiny as application libraries. A convenient third-party action may execute with repository or cloud credentials. Its permissions should be minimised, versions should be controlled, and changes should be reviewed.

7. Retention, Audit Trails, and Evidence

Retention is the deliberate preservation and deletion of records according to business, legal, contractual, privacy, and operational needs. Retaining everything forever is not automatically safer. Excessive retention increases exposure, storage cost, and privacy risk; insufficient retention can prevent incident investigation or regulatory demonstration.

A retention schedule should identify the record, owner, purpose, retention period, storage location, and disposal method. Examples include pull-request approvals, deployment records, access changes, security-scan results, incident records, and release metadata. The exact period depends on organisational and legal requirements and should be established with appropriate legal, compliance, and security advice.

An audit trail should be sufficiently reliable to answer who performed an action, what was changed, when it occurred, from where or through which system, and whether the action succeeded. Logs should be protected from unauthorised alteration, access should be restricted, and timestamps should use a consistent time reference. Audit records themselves can contain sensitive information, so they require classification and access control.

A commit log is not a complete audit trail. It may omit web-interface actions, permission changes, workflow approvals, deployment events, or deleted resources. Effective governance correlates Git events with identity-provider, CI/CD, cloud, and ticketing records.

8. Ethics and Responsible Authorship

Technical authority does not remove professional responsibility. Ethical Git practice includes honesty, respect for privacy, preservation of evidence, proper attribution, and avoidance of foreseeable harm.

Important situations include:

• Plagiarism and licence compliance: copied code must be used consistently with its licence and attributed where required.
• Misleading history: developers should not manipulate timestamps, authorship, or review records to create false evidence.
• Conflicts of interest: reviewers should disclose relationships or incentives that may affect judgement.
• Privacy: personal data should not be placed in issues, commits, test fixtures, or logs without a legitimate purpose and appropriate safeguards.
• Vulnerability disclosure: security weaknesses should be reported through responsible channels rather than publicly exposing exploitable details prematurely.
• AI-assisted development: developers remain responsible for reviewing generated code, checking licences and provenance, avoiding confidential prompts, testing for vulnerabilities, and documenting material use where policy requires it.

Ethical conduct is not merely individual morality. Organisational incentives influence behaviour. Unrealistic delivery targets, approval metrics based only on speed, or punishment for reporting mistakes can encourage concealment and unsafe shortcuts. A mature governance culture rewards transparent reporting and learning while maintaining accountability for deliberate misconduct.

9. A Practical Governance Framework

A small team can implement governance through a repeating lifecycle:

1. Classify: identify repository sensitivity, criticality, data types, and regulatory obligations.
2. Assign ownership: name technical, security, and business owners.
3. Control access: apply least privilege, MFA, team-based roles, and periodic reviews.
4. Protect change: enforce branch rules, reviews, testing, and signed release evidence where justified.
5. Scan and verify: inspect secrets, dependencies, licences, and build artefacts.
6. Monitor: collect protected audit records and investigate anomalies.
7. Respond: rotate exposed credentials, contain incidents, communicate responsibly, and preserve evidence.
8. Improve: review incidents, exceptions, metrics, and policy effectiveness.

Useful indicators include the percentage of repositories with protected default branches, the percentage of privileged accounts reviewed on schedule, secret-detection findings, dependency remediation age, signed-release coverage, and the time taken to revoke an exposed credential. Metrics should support improvement rather than encourage teams to hide findings.

Applied Case: The Northstar Deployment Repository

Background

Northstar, an illustrative online-service team, stores application code in a hosted Git repository. Six developers, two operations engineers, and an automated deployment workflow use the repository. The default branch is not protected, and a cloud access key is stored in a configuration file.

Problem

A developer notices that the key was committed several weeks earlier. The repository is private, but a contractor and an automated build service have access. The team also discovers that anyone with write access can alter the deployment workflow and that dependency updates are applied manually without a review record.

Analysis

The key represents an immediate confidentiality and integrity risk. Privacy of the repository does not eliminate the possibility of accidental disclosure through clones, logs, backups, or compromised accounts. The unprotected workflow creates a path to modify production deployment behaviour. Weak dependency governance increases supply-chain risk, while the absence of reliable review evidence limits investigation.

Approach and Solution

The team first disables and replaces the cloud key, checks access logs, and informs the security owner. It removes the key from active configuration and coordinates history cleanup. A secret manager is introduced, and the deployment job receives a narrowly scoped, short-lived identity.

The default branch is protected. Pull requests now require one qualified approval, passing tests, and successful secret and dependency scans. Direct pushes and force-pushes are disabled. Release tags are created by a controlled workflow, and release commits are signed using a team-approved method.

The team performs an access review, removes the contractor’s expired membership, enables MFA, and separates administration from ordinary development. Dependency manifests and lockfiles are committed, automated update proposals are reviewed, and high-risk workflow changes require operations approval. Repository, identity, CI/CD, and deployment logs are retained according to an approved schedule.

Outcome

The exposed credential is no longer valid, and subsequent deployments use an auditable identity. Review evidence becomes available for each production change. The team detects vulnerable dependencies earlier and can reconstruct relevant actions during an incident. Developers also receive guidance on secret handling, attribution, and responsible AI-assisted coding.

Learning Points

The case demonstrates that no single control is sufficient. Secret scanning would not replace credential rotation; signed commits would not prevent an authorised malicious change; branch protection would not correct excessive cloud permissions. Security emerges from layered controls, clear ownership, and an organisational willingness to respond promptly and honestly.

Challenges and Limitations

Governance can become counterproductive when controls are excessive, unclear, or disconnected from risk. Requiring complex approvals for every documentation change may encourage workarounds. Automated scanners generate false positives and may create alert fatigue. Signing keys can be lost or compromised. Retention can conflict with privacy minimisation. Dependency tools may report theoretical vulnerabilities while missing malicious package behaviour. Finally, technical controls cannot resolve ambiguous ownership or unethical incentives by themselves.

Controls should therefore be reviewed for usability, coverage, and effectiveness. Exceptions should be documented with an owner, reason, expiry date, and compensating controls. Emergency access should be monitored and reviewed afterward. The goal is not perfect prevention, which is unrealistic, but reduced likelihood, limited impact, rapid detection, and accountable recovery.

Best-Practice Checklist

Before declaring a repository production-ready, verify that:

• ownership and data classification are documented;
• MFA and individual accounts are required;
• permissions follow least privilege and are periodically reviewed;
• secrets are managed outside source code;
• default and release branches are protected;
• reviews, tests, and security checks are enforced;
• important commits or releases have verifiable signatures;
• secret and dependency scanning is active;
• dependencies, actions, and licences are reviewed;
• audit records are protected and retained appropriately;
• incident, credential-rotation, and emergency-access procedures exist;
• authorship, attribution, privacy, and AI-use expectations are clear.

Chapter Summary

Git repositories are governed assets that require confidentiality, integrity, availability, and accountable ownership. Least privilege limits the damage caused by mistakes or compromised identities, while MFA, individual accounts, team-based permissions, and access reviews strengthen identity management. Protected branches, review requirements, testing, and separation of duties reduce unauthorised or unreviewed change.

Signed commits support provenance but do not prove code quality or eliminate the need for review. Secrets should remain outside Git, and exposed credentials must be revoked or rotated immediately; history rewriting is only a supplementary containment measure. Dependency controls address vulnerabilities, licences, provenance, and supply-chain risks. Retention schedules and correlated audit trails provide evidence without retaining information indefinitely.

Ethical practice requires honest authorship, proper attribution, privacy protection, responsible disclosure, and critical review of AI-generated code. Effective governance is layered, risk-based, measurable, and adaptable. It combines technical safeguards with clear policies, responsible people, and a culture that encourages prompt reporting and continuous improvement.

Key Terms

Least privilege: Granting only the access required for an approved task.

Protected branch: A branch governed by rules such as required reviews, tests, and restricted pushes.

Pull request: A proposed change submitted for review before integration.

Signed commit: A commit accompanied by cryptographic evidence from a signing key.

Provenance: Evidence about the origin and history of code or an artefact.

Secret: Confidential information, such as a password, token, or private key, that can enable access.

Secret scanning: Automated detection of likely credentials or sensitive patterns.

Credential rotation: Replacing an existing credential with a new one.

Dependency: External software required by an application, tool, or build process.

Transitive dependency: A dependency required indirectly through another dependency.

Lockfile: A file recording resolved dependency versions and often integrity data.

Software bill of materials (SBOM): An inventory of components in a software product.

Separation of duties: Dividing responsibilities so one person cannot complete a high-risk process alone.

Audit trail: Protected records of actions, identities, times, and outcomes.

Retention policy: Rules defining what records are kept, why, and for how long.

Data minimisation: Limiting collection and retention to what is necessary.

Responsible disclosure: Reporting a vulnerability through an appropriate channel and allowing reasonable remediation.

Repository governance: Policies, roles, controls, and evidence governing repository use.

Review Questions

Short Answer Questions

1. What is the principle of least privilege?
2. Why is deleting a secret in a later commit not sufficient remediation?
3. State two controls commonly applied to a protected branch.
4. What does a signed commit help demonstrate?
5. Why should shared user accounts generally be avoided?

Long Answer Questions

1. Explain how protected branches, code review, automated testing, and separation of duties work together to govern production changes.
2. Describe a complete response to the accidental commitment of a cloud credential.
3. Discuss the benefits and limitations of dependency scanning and lockfiles.
4. Explain why a commit history alone is not a complete audit trail.
5. Discuss the ethical responsibilities of a developer using AI-assisted code generation.

Analytical / Application Questions

1. A small team gives every developer repository administration rights because it is convenient. Analyse the risks and propose a staged least-privilege design.
2. A secret-scanning tool reports many false positives, so the team disables it. Evaluate this decision and design a safer alternative.
3. A contractor’s account is used to modify a deployment workflow outside the normal review process. Identify the likely governance failures and specify the evidence and corrective actions required.

Multiple Choice Questions with Answers

Question 1

Which practice best implements least privilege for a CI/CD test job?

A. Give the job repository-owner permissions

B. Give the job only the permissions required to run tests and publish results

C. Use a developer’s personal administrator token

D. Allow the job to delete branches after testing

Correct Answer: B. Give the job only the permissions required to run tests and publish results

Question 2

What is the first priority when a valid cloud credential is committed to a repository?

A. Rename the file containing the credential

B. Rewrite the entire repository history

C. Revoke or rotate the credential

D. Make the repository public for transparency

Correct Answer: C. Revoke or rotate the credential

Question 3

Which control most directly prevents unreviewed direct changes to the main branch?

A. A protected-branch rule

B. A larger repository

C. A longer commit message

D. A local text editor setting

Correct Answer: A. A protected-branch rule

Question 4

What does a signed commit primarily provide?

A. Proof that the code contains no vulnerabilities

B. Cryptographic evidence associated with a signing key

C. A guarantee that all dependencies are licensed

D. Automatic removal of secrets from history

Correct Answer: B. Cryptographic evidence associated with a signing key

Question 5

Why are lockfiles useful?

A. They grant administrators additional privileges

B. They record resolved dependency versions for reproducibility

C. They permanently eliminate dependency vulnerabilities

D. They replace the need for code review

Correct Answer: B. They record resolved dependency versions for reproducibility

Question 6

Which statement about secret scanning is most accurate?

A. A passing scan proves that no secrets exist

B. Secret scanning can detect every credential format

C. Secret scanning is useful but may miss secrets and produce false positives

D. Secret scanning makes credential rotation unnecessary

Correct Answer: C. Secret scanning is useful but may miss secrets and produce false positives

Question 7

Which item is normally part of an audit trail?

A. Only the final source-code file

B. The identity, time, action, and outcome of an event

C. A developer’s private password

D. An unverified rumour about a deployment

Correct Answer: B. The identity, time, action, and outcome of an event

Question 8

Which action reflects responsible authorship?

A. Claiming all AI-generated code as entirely original without review

B. Copying restricted code without checking its licence

C. Attributing contributions and reviewing generated code for quality and risk

D. Rewriting history to conceal an unpopular design decision

Correct Answer: C. Attributing contributions and reviewing generated code for quality and risk

Question 9

Why is retaining every repository record forever potentially harmful?

A. It always prevents auditing

B. It can increase privacy, exposure, and storage risks

C. It guarantees that dependencies become outdated

D. It disables branch protection

Correct Answer: B. It can increase privacy, exposure, and storage risks

Question 10

Which statement best describes signed commits?

A. They prove that the signer personally wrote every line

B. They prove that the code is safe to deploy

C. They strengthen provenance but do not replace review and testing

D. They automatically revoke compromised credentials

Correct Answer: C. They strengthen provenance but do not replace review and testing