Governance, Security and Ethical Practice

Introduction

Git and version control are often introduced as technical tools for recording changes to files. In professional data-science work, however, a repository is also a governed information system. It may contain source code, notebooks, datasets, model definitions, credentials, documentation, research evidence and a historical record of who changed what and when. Poor governance can therefore produce more than merge conflicts: it can expose personal information, violate software licences, undermine reproducibility, create security vulnerabilities or make accountability impossible.

Governance is the system of rules, responsibilities and decision processes used to direct and control repository activity. Security protects code, data, identities and infrastructure from unauthorised access or harmful change. Ethical practice concerns what contributors ought to do, including honest authorship, respect for privacy, responsible disclosure and avoidance of harmful or misleading analysis. These dimensions overlap. For example, requiring code review is simultaneously a governance control, a security measure and an ethical safeguard against unexamined decisions.

This chapter presents a practical framework for governing Git repositories in data-science environments. It addresses access control, branch protection, commit signing, secret scanning, licensing, privacy, audit requirements, authorship, responsible contribution and repository retention.

Learning objectives

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

• distinguish governance, security, compliance and ethical responsibility in version-controlled work;
• design appropriate repository roles and access controls;
• apply branch protection, pull-request review and separation-of-duties principles;
• explain the value and limitations of signed commits and secret scanning;
• select suitable licensing and attribution practices;
• identify privacy and data-protection risks in code, notebooks, commits and datasets;
• maintain useful audit trails and retention policies;
• handle authorship, contribution credit, vulnerability disclosure and repository retirement responsibly.

1. The repository as a governed system

A repository has at least four important assets:

1. Content: code, configuration, documentation, tests, notebooks and data.
2. History: commits, branches, tags, reviews, issue discussions and releases.
3. Identities: user accounts, service accounts, deploy keys and signing keys.
4. Relationships: dependencies, deployment systems, data stores and external services.

A governance programme should answer five questions:

• Who may access the repository?
• Who may change protected content?
• How are changes reviewed and attributed?
• How long must records and artefacts be retained?
• What happens when a contributor leaves, a secret is exposed or a project ends?

A useful principle is least privilege: each identity receives only the access necessary for its legitimate task, for only as long as necessary. Least privilege does not mean that everyone has identical restrictions. A data scientist may need to create branches and run tests, while a release manager may approve production tags. A deployment service may need read access to a particular repository but should not have general administrative authority.

Governance must also be proportionate. A small student project does not require the same controls as a repository containing health records or code that controls financial decisions. Nevertheless, the underlying questions remain the same.

Important terminology

• Repository: a Git database containing files, objects and their history.
• Remote: a repository hosted elsewhere, such as on an organisational platform.
• Branch: a movable reference to a line of development.
• Protected branch: a branch subject to rules such as review or successful tests.
• Commit: a recorded snapshot with metadata and a parent relationship.
• Pull request or merge request: a proposed change submitted for review.
• Role-based access control (RBAC): assigning permissions through roles rather than individually whenever possible.
• Audit trail: records that allow actions and decisions to be reconstructed.
• Personally identifiable information (PII): information that identifies, or can reasonably be linked to, a person.
• Secret: confidential authentication or encryption material, such as a token, password or private key.

2. Access control and identity management

2.1 Authentication and authorisation

Authentication establishes who an actor is; authorisation determines what that actor may do. A strong Git governance design uses both:

• organisational single sign-on where available;
• multi-factor authentication, especially for administrators;
• individual accounts rather than shared human accounts;
• centrally managed membership and prompt removal of leavers;
• separate service identities for automated jobs;
• periodic review of memberships, tokens, deploy keys and outside collaborators.

A password alone is a weak control because it can be guessed, reused or stolen. Multi-factor authentication improves resistance to credential theft, although it does not eliminate phishing or compromised devices.

2.2 Roles and permissions

Common repository roles include the following:

Permissions should be granted to teams or groups where possible. Individual exceptions are difficult to review and often remain after the original need has ended. Administrative access should be limited, logged and reviewed. A repository administrator should not automatically be the only person capable of releasing software; concentration of authority creates operational and ethical risk.

2.3 Separation of duties

Separation of duties means that one person cannot unilaterally perform every significant step in a sensitive process. For example, the person who writes a change may not be the person who approves and releases it. This principle reduces the likelihood that an error or malicious action will pass unnoticed.

A practical workflow may require:

1. a contributor to create a feature branch;
2. automated tests and security checks to run;
3. one or more qualified reviewers to approve the change;
4. a maintainer to merge it into a protected branch;
5. a release process to create an immutable version tag.

The number and independence of reviewers should match the risk. A spelling correction does not need the same process as a change to a model used in clinical triage.

3. Branch governance and change control

3.1 Branch protection

A protected main or production branch commonly requires:

• changes through pull requests rather than direct pushes;
• successful automated tests and quality checks;
• review by an authorised person;
• resolution of review comments before merging;
• restrictions on force-pushing and branch deletion;
• signed commits or signed merge commits where appropriate;
• an up-to-date dependency and vulnerability check.

These rules protect the integrity of the branch, but they are not substitutes for judgement. A test can pass while an analysis uses biased data, violates a licence or exposes personal information.

3.2 Branch naming and commit messages

Consistent branch names make work discoverable. Examples include feature/customer-segmentation, bugfix/null-date-handling and security/rotate-api-token. Commit messages should state the purpose and, where useful, the effect of the change. A message such as “fix” creates little audit value; “validate missing dates before cohort calculation” is more informative.

Commits should normally be focused and coherent. Combining an unrelated refactor, data deletion and dependency upgrade in one commit makes review and rollback difficult. However, history should not be manipulated merely to conceal mistakes. Squashing commits may produce a cleaner public history, but the project should preserve any audit information required by policy.

3.3 Pull requests as evidence

A pull request should communicate:

• the problem being addressed;
• the proposed solution;
• tests or validation performed;
• impacts on data, privacy, security and licences;
• known limitations and rollback considerations.

Review is not simply approval of syntax. Reviewers should ask whether the change is correct, necessary, comprehensible, safe and consistent with the project’s obligations.

4. Commit signing and provenance

A commit records an author name and email, but these fields are editable and do not by themselves prove identity. Commit signing adds a cryptographic signature made with a private key. The hosting platform can verify the signature using the corresponding public key and associate it with a known account.

Signing supports provenance: evidence about who authorised a commit. It is especially useful for release commits, security-sensitive changes and regulated workflows. A signed commit does not prove that the code is correct, that the author reviewed every line or that the author acted ethically. It proves, subject to key security and verification policy, that a particular key signed the commit.

Good key-management practice includes:

• protecting private keys with strong passphrases or secure hardware;
• registering only the public key with the hosting platform;
• keeping recovery and revocation procedures;
• using separate keys when organisational policy requires separation;
• removing or revoking keys when devices are lost or contributors leave;
• recognising that a valid signature made with a stolen key is not trustworthy.

Signed commits should be combined with protected branches and verified reviews. Cryptographic provenance is one layer in a defence-in-depth model, not a replacement for access control.

5. Secrets and software supply-chain security

5.1 What counts as a secret?

Secrets include cloud access keys, database passwords, private certificates, OAuth tokens, encryption keys and credentials embedded in configuration files. A secret can be exposed in source code, notebook output, an issue, a log, a container image or Git history. Deleting the current file does not necessarily remove it from earlier commits or from cloned repositories.

Secrets should be stored in an approved secret manager or protected environment configuration. Code should refer to a variable or managed secret rather than containing the secret itself. Example configuration files may contain placeholders, not real credentials.

5.2 Secret scanning and incident response

Secret-scanning tools search commits and files for patterns associated with credentials. They may operate before a commit, during a pull request or continuously across repository history. Scanning is valuable but imperfect: it can produce false positives and may miss novel or encoded secrets.

If a real secret is exposed, the correct response is not merely to delete the line:

1. treat the secret as compromised;
2. revoke or rotate it immediately;
3. determine where it appeared, including history and logs;
4. assess access and possible misuse;
5. remove the exposure where policy permits;
6. document the incident and improve controls.

Rotation changes the credential; history rewriting alone does not. Rewriting history can also damage clones, audit trails and references, so it requires deliberate authorisation.

Supply-chain security also includes dependency pinning, vulnerability monitoring, review of third-party packages, restricted build permissions and reproducible environments. A data-science notebook may depend on dozens of packages; an unreviewed dependency can introduce vulnerabilities or alter analytical results.

6. Licensing and intellectual property

Software licences define permissions and obligations concerning use, modification, distribution and attribution. A repository is not automatically free of copyright restrictions merely because it is accessible online. Data, code, model weights, documentation and images may each have different rights.

A project should identify:

• the licence for original code;
• licences of dependencies and copied snippets;
• terms governing datasets and model artefacts;
• attribution and notice requirements;
• restrictions on commercial use, redistribution or derivative works;
• compatibility issues between licences.

Permissive licences, such as MIT-style licences, generally allow broad reuse subject to conditions such as retaining notices. Copyleft licences impose additional obligations when covered software is distributed in derivative forms. The correct choice depends on institutional policy and project objectives; it should not be made from a superficial label such as “open source.” Legal or institutional advice may be required.

Every repository should include a clear licence file where appropriate, a third-party notices file when required, and documentation identifying data-use restrictions. Do not upload proprietary code, copyrighted datasets or confidential material merely because a technical platform permits it.

7. Privacy and data protection

7.1 Data minimisation

The safest sensitive dataset is often the one never copied into the repository. Data minimisation means collecting, storing and exposing only what is necessary for a defined purpose. Repositories should generally contain code and documented procedures, not raw customer records, health information, student records or unredacted survey responses.

Privacy risks occur in unexpected places:

• notebook cells containing sample rows;
• plots with names or identifiable labels;
• error messages and logs;
• filenames and commit messages;
• issue discussions and screenshots;
• test fixtures that resemble real records;
• metadata, timestamps or location fields.

Removing a column may not anonymise data if combinations of remaining fields permit re-identification. Pseudonymisation replaces direct identifiers but leaves a linkage risk if a key exists elsewhere. Anonymisation aims to prevent identification, but its success depends on context and available auxiliary information.

7.2 Lawful and ethical handling

The applicable legal framework depends on jurisdiction and sector. Common principles include purpose limitation, data minimisation, accuracy, security, retention limitation and accountability. Ethical practice goes beyond legal minimums: a technically lawful reuse may still violate participant expectations or create unfair harm.

Before committing data or analytical outputs, ask:

• What is the purpose of this data?
• Do we have authority and an appropriate basis to use it?
• Can individuals be identified directly or indirectly?
• Is the repository access level appropriate?
• How long should the data and derived artefacts be retained?
• Can the same purpose be achieved with synthetic, aggregated or de-identified data?

Synthetic data can support testing, but it is not automatically risk-free. If generated from a small or sensitive source, it may reproduce identifying patterns or confidential information.

8. Auditability, reproducibility and retention

An audit trail should allow an authorised person to reconstruct important events: who proposed a change, what was reviewed, which tests ran, who approved it, what was released and when. Useful evidence includes commit identifiers, pull-request discussions, CI results, release tags, dependency manifests and deployment records.

Auditability is not the same as recording everything forever. Excessive retention increases privacy, storage and breach risks. A retention schedule should classify artefacts and specify duration, owner, storage location, legal hold procedures and secure disposal. For example, production release evidence may need longer retention than temporary build logs, while personal data should not be retained merely because storage is inexpensive.

A repository retirement process should include:

1. identifying the owner and successor owner;
2. marking the repository read-only or archived;
3. documenting the final version, dependencies and operational status;
4. revoking tokens, deploy keys and unnecessary memberships;
5. preserving records required for research, legal or regulatory purposes;
6. deleting data that no longer has a valid retention purpose;
7. communicating where users should find the supported replacement.

Retention and deletion can conflict. A legal hold may require preservation; privacy obligations may require deletion. Such conflicts should be escalated to the responsible governance or legal authority rather than resolved informally by a developer.

9. Authorship, contribution and responsible collaboration

9.1 Attribution is an ethical practice

Git records activity, not the whole intellectual contribution. A person may contribute through experimental design, data collection, domain expertise, documentation, review, testing, infrastructure or project leadership without making many commits. Conversely, a large number of trivial commits does not necessarily represent major intellectual contribution.

Projects should define contribution expectations at the beginning. Contribution files, author statements and release notes can recognise different forms of work. Do not erase a contributor’s work by rewriting history without considering attribution and audit requirements. Do not add a person as an author merely to reward status if they did not contribute.

9.2 Responsible contribution

Responsible contributors:

• read the project’s contribution and security policies;
• protect confidential information;
• disclose uncertainty and limitations;
• avoid discriminatory or harmful uses of data and models;
• report vulnerabilities privately through the designated channel;
• respond respectfully to review and disagreement;
• document decisions sufficiently for future maintainers;
• use automation and AI tools transparently where policy requires.

AI coding assistants can generate insecure, incompatible or licence-sensitive code. A contributor remains responsible for reviewing generated material, testing it, checking provenance and protecting prompts or pasted data. AI assistance does not transfer accountability to the tool.

10. A practical governance workflow

The following workflow is suitable for many diploma-level projects:

1. Classify the repository: identify sensitivity, criticality, data types and regulatory obligations.
2. Assign ownership: name a maintainer and a deputy; document escalation contacts.
3. Configure identity controls: enable multi-factor authentication, teams and least-privilege roles.
4. Define contribution rules: establish branch naming, review, testing, signing and disclosure requirements.
5. Protect important branches: prevent direct pushes and force-pushes; require appropriate checks.
6. Control secrets: use secret storage, scanning and a documented rotation procedure.
7. Control dependencies and licences: maintain manifests, notices and vulnerability checks.
8. Protect privacy: prohibit raw sensitive data and inspect notebooks, outputs and history.
9. Record decisions: retain review, release and incident evidence according to schedule.
10. Review and improve: periodically test access, examine exceptions and update policies.

Controls should be tested. A policy that says “review is required” is weak if a maintainer can silently bypass it without a logged reason. Conversely, controls that create constant false alarms will be ignored. Governance must be usable, monitored and proportionate.

Illustrative case study: the Riverside Mobility Repository

Background

Riverside Mobility is an illustrative university project analysing bus usage. The team stores Python code, notebooks, aggregated passenger counts and a model that predicts route demand. The repository is hosted on an organisational Git platform and is shared with a transport partner.

Problem

A student commits a notebook containing several rows of passenger data and an API token used to retrieve weather data. The main branch allows direct pushes. A second student copies a plotting function from an online project without recording its licence. The project supervisor must prepare a reproducible report while ensuring that no personal information is exposed.

Analysis

The incident involves several distinct risks:

• the API token could permit unauthorised service use;
• passenger records may be identifiable when combined with route and time information;
• deleting the visible notebook will not remove the token from Git history;
• the copied code may impose attribution or redistribution obligations;
• direct pushes and weak review reduce confidence in the report’s provenance.

The team must avoid treating this as only a coding error. It is simultaneously a security, privacy, intellectual-property and governance problem.

Approach and solution

The supervisor first asks the service owner to revoke and replace the exposed token. The repository history and CI logs are checked for further exposure. The notebook is replaced with a version using synthetic examples, and the raw data is moved to an approved restricted store. The team documents the data purpose, access permissions and retention period.

The copied plotting function is traced to its original project. Its licence and attribution requirements are recorded, and the team replaces it if the licence is incompatible with the intended distribution. A licence file and third-party notice are added to the repository.

The main branch is protected. Changes now require a pull request, successful tests, a privacy check and approval by someone other than the author. Secret scanning and dependency checks are enabled. Release tags identify the version used for the final report. Contributors record their roles in a contribution statement, including data preparation, domain review and documentation.

Outcome

The final report can be reproduced from approved data and documented scripts without exposing passenger records or active credentials. Reviewers can identify the release version and the evidence behind it. The repository contains less raw material but provides stronger scientific and governance value.

Learning points

The case demonstrates that security controls must cover history, not only current files. Privacy review must include notebooks and outputs. Licensing is part of technical planning. Finally, reproducibility does not require publishing confidential data; it requires documenting the method, assumptions, versions and approved access route.

Challenges and limitations

No control is perfect. Branch protection may slow urgent fixes; signing depends on secure key management; scanners can miss secrets; anonymisation can fail under linkage attacks; licence interpretation can be complex; and audit logs may contain sensitive metadata. Excessive bureaucracy may encourage work outside approved repositories, creating a shadow system with weaker controls.

Governance also involves power. A contributor who cannot challenge an unsafe or discriminatory use of data may be formally authorised but ethically constrained. Organisations should provide confidential escalation channels and protect good-faith reporting. Policies should be reviewed with technical, legal, privacy and domain stakeholders rather than imposed without consultation.

Contemporary developments and best practices

Modern development platforms increasingly integrate policy-as-code, automated dependency updates, software bills of materials, provenance attestations and continuous secret scanning. These tools can improve consistency, but automation should produce explainable results and a route for human review. Automated approval is inappropriate where context, consent or potential harm cannot be evaluated mechanically.

For data-science teams, a strong baseline is:

• private-by-default repositories for sensitive work;
• multi-factor authentication and least privilege;
• protected branches and peer review;
• signed releases for important artefacts;
• secret scanning and rapid credential rotation;
• dependency and licence inventories;
• synthetic or controlled test data;
• documented data lineage and model limitations;
• contribution and disclosure policies;
• retention, archival and deletion procedures.

Governance should be treated as a lifecycle. It begins before the first commit, continues through development and release, and ends only when access, data and records have been responsibly retired.

Chapter Summary

A Git repository is both a technical workspace and an organisational record. Effective governance combines least-privilege access, multi-factor authentication, role separation, protected branches, peer review and clear ownership. Signed commits strengthen provenance but do not establish correctness or ethical legitimacy. Secret scanning is useful, yet exposed credentials must be revoked or rotated because deleting a file does not remove historical exposure.

Licensing applies to code, data, documentation and dependencies. Privacy requires attention to notebooks, outputs, logs, metadata and re-identification risk, not merely to obvious database columns. Auditability depends on meaningful history, review evidence, release records and appropriate retention. Ethical practice includes honest attribution, responsible disclosure, transparent limitations and careful use of AI-assisted development. The central professional principle is that secure and ethical version control is a continuous, proportionate process of accountability.

Key Terms

Governance: Rules, responsibilities and processes used to direct and control repository activity.

Least privilege: Giving an identity only the access required for its legitimate task.

Authentication: Establishing the identity of a user or service.

Authorisation: Determining what an authenticated identity may do.

Role-based access control: Assigning permissions through defined organisational roles.

Separation of duties: Dividing sensitive tasks so one person cannot complete every step alone.

Protected branch: A branch governed by restrictions such as review and successful tests.

Provenance: Evidence about the origin, authorisation and history of an artefact.

Commit signing: Using a cryptographic signature to support verification of commit origin.

Secret: Confidential authentication, encryption or authorisation material.

Secret scanning: Automated detection of likely credentials in files or history.

Licence: Legal terms governing use, modification, attribution and distribution.

Personally identifiable information: Information that identifies or can reasonably be linked to a person.

Pseudonymisation: Replacing direct identifiers while retaining a possible linkage risk.

Audit trail: Records that permit significant actions and decisions to be reconstructed.

Retention schedule: A documented rule specifying how long artefacts are kept and when they are disposed of.

Responsible disclosure: Reporting a vulnerability privately and appropriately before public disclosure.

Contribution statement: A record of the different roles and work performed by contributors.

Review Questions

Short Answer Questions

1. What is the difference between authentication and authorisation?
2. Why does deleting an exposed secret from the latest version not fully resolve the incident?
3. State two purposes of protecting a main branch.
4. Why is a signed commit not proof that code is correct?
5. Give two examples of privacy exposure that may occur in a notebook.

Long Answer Questions

1. Explain how least privilege and separation of duties can be implemented in a data-science repository.
2. Discuss the relationship between licensing, attribution and dependency management.
3. Describe a suitable audit and retention approach for a repository containing a production model.
4. Explain how privacy, reproducibility and data minimisation can be balanced.
5. Evaluate the advantages and limitations of automated secret scanning and policy checks.

Analytical / Application Questions

1. A student pushes a real database password, then deletes the file and force-pushes the branch. Analyse the remaining risks and propose an incident-response sequence.
2. Design a branch and review policy for a team developing a model that influences access to public services. Justify each major control.
3. A repository contains copied code, a third-party dataset, AI-generated functions and identifiable notebook examples. Develop a governance plan addressing authorship, licensing, privacy, security and retention.

Multiple Choice Questions with Answers

Question 1

Which control best prevents a contributor from directly changing the protected main branch?

A. A protected-branch rule requiring pull requests

B. A descriptive branch name

C. A larger repository storage quota

D. A local editor configuration

Correct Answer: A. A protected-branch rule requiring pull requests

Question 2

What is the correct immediate response when an active API token is committed?

A. Rename the file and continue working

B. Revoke or rotate the token and investigate exposure

C. Add the token to the README for transparency

D. Only delete the latest commit message

Correct Answer: B. Revoke or rotate the token and investigate exposure

Question 3

What does a valid commit signature primarily provide?

A. Proof that the program has no defects

B. Proof that the data is unbiased

C. Evidence that a particular key authorised the commit

D. Evidence that all dependencies are licensed

Correct Answer: C. Evidence that a particular key authorised the commit

Question 4

Which practice most directly applies the principle of least privilege?

A. Giving every contributor administrator access

B. Using one shared account for the whole team

C. Granting a deployment service only the permissions it needs

D. Publishing all credentials in project documentation

Correct Answer: C. Granting a deployment service only the permissions it needs

Question 5

Why should raw personal data generally not be stored in a shared Git repository?

A. Git cannot store text files

B. Repository history and copies can preserve or expose the data

C. Personal data always makes tests fail

D. Private repositories are never access-controlled

Correct Answer: B. Repository history and copies can preserve or expose the data

Question 6

Which statement about pseudonymisation is most accurate?

A. It always makes re-identification impossible

B. It removes every privacy obligation

C. It replaces direct identifiers but may retain linkage risk

D. It is identical to deleting the dataset

Correct Answer: C. It replaces direct identifiers but may retain linkage risk

Question 7

What is the main purpose of a software licence in a repository?

A. To define permissions and obligations for use and distribution

B. To guarantee that the software is secure

C. To prevent all collaboration

D. To replace code review

Correct Answer: A. To define permissions and obligations for use and distribution

Question 8

Which contribution practice is ethically strongest?

A. Credit only people with the most commits

B. Recognise meaningful technical, domain, review and documentation work

C. Remove inconvenient contributors from the history

D. Assign authorship automatically to the repository administrator

Correct Answer: B. Recognise meaningful technical, domain, review and documentation work

Question 9

Why is repository retention policy needed?

A. To keep every file forever regardless of sensitivity

B. To define justified preservation and secure disposal of records

C. To eliminate the need for backups

D. To ensure old credentials remain available

Correct Answer: B. To define justified preservation and secure disposal of records

Question 10

What is the most appropriate role for AI-generated code in a governed repository?

A. It can be merged without review because the tool is responsible

B. It should be reviewed, tested and checked for security and provenance

C. It should always be prohibited from documentation

D. It automatically satisfies licence obligations

Correct Answer: B. It should be reviewed, tested and checked for security and provenance