Security Pattern – Source Code Management

Overview

The following security pattern describes controls for protection of company developed source code from external and internal threats. Source code management is utilised to track modifications to a source code repository, maintain history of changes to a code base and helps resolve conflicts when merging updates from multiple contributors.

The use of git repositories as a distributed source code management has become the defacto solution for most organisations, rather than traditional centralised source code version control solutions.

Common examples of technology vendors providing source code management include Atlassian BitBucket, GitHub, GitLab, AWS CodeCommit and Azure Repos.

Typical challenges

Scope

The scope of this document is for addressing the security threats that relate to

ID Description Example
01 Protection of code being maintained within Git source code repository Examples of vendors providing source code repository include GitHub, Atlassian Bitbucket, AWS CodeCommit.
02 Access to source code repository from developers’ workstations. Local developer workstations (Windows or Linux based) used to clone, branch or merge source code.
03 Replication of source code repository to 3rd party partners Source code repositories maybe sync’d or replicated to external service providers or outsourced suppliers.

Out of Scope 

ID Description of exclusion Reason for Exclusion
01 Security controls for software artefact repositories Considered separate security pattern.

Dependencies

ID Description Impact from dependency not met
01 Summarised security design principles outlined under Jericho Forum® Commandments. https://publications.opengroup.org/w124 Minimal impact as these principles are used as an example set of baseline requirements within security pattern.

Constraints

ID Description Impact from constraint
01 This pattern is constrained to just git version control and not traditional Subversion (SVN) Minimal impact as SVN is considered depreciated version control mechanism.

Assumptions

ID Description Impact if assumption is false
01

Assets at Risk

The following section provides a list of assets affected by the problem statement:

Asset Title Asset Description
Source Code Management and Version Control Overall system and management services hosting git repositories and enforcement of version control, system access and audit logs
Source Code GIT Repositories – Public Primary git repository containing source code artefacts configured to allow access from external hosting locations
Source Code GIT Repositories - Private Primary git repository containing source code artefacts configured restricted to private access. These repositories can also be replicated/sync to other remote or partner locations.
Developer Workstations Local developer workstations used by repository owners and contributors to push, pull or commit source code to git repositories.
CI/CD Pipelines Continuous integration and delivery pipelines for maintaining software development lifecycle and workflows.

The following assets are also referenced within the pattern but not in scope

Threat Model

The following section provides a list of threats within the problem statement:

Threat Event (ID / Title) Threat Description and Characteristics Diagram
TE-09: Accidental leaks or sharing of information due to human error or mishandling Source code may unintentionally contain sensitive information such as passwords, SSH keys, access tokens may be accidently or inadvertently checked in to the source code repository and subsequently exposed to any malicious entity with read access.
TE-14: Inadequate workflows or processes leading to flaws in deployment Contributors may unintentionally commit vulnerable code into source code repositories causing loss of confidence in target system. Security flaws within code may be introduced at any stage of the software development lifecycle and workflows. Remediate flaws can also be re-introduced due to poor code management practises or development workflows.
TE-16: Unintentional destruction of records through mismanaged data repositories or storage Repository or system administrators could unintentionally corrupt or delete source code repositories with the result of causing unavailability or inaccessibility to source code.
TE-29: Web application attacks or code injection attack Software used to manage and administrate source code repositories maybe vulnerable to web applications attacks against exposed API interfaces, manipulation of webhooks or manipulation of command parameter / arguments.
TE-31: Unauthorized changes or manipulation of application functionality or code Trusted internal or partner developers may intentionally commit vulnerable code or perform unauthorised changes with the intent to later exploited those weakness within the target application, system or business processes.
TE-34: Violate isolation in multi-tenant environment Tenet overlap between source code contributors could lead to code being committed incorrectly to the wrong code repository (with less permissive restrictions or controls) or subverting permissions boundaries across different source code repositories to perform unauthorised changes.
TE-36: Unauthorized changes or manipulation of information data records Unauthorised changes to git repositories through malicious insider or ransomware could intentionally encrypt or remove git repositories with the intent of causing unavailability or inaccessibility to source code.
TE-37: Compromise of confidential information or data breach Confidentiality of source code could be compromised through lack of validation of external entities or 3rd party applications accessing source code repositories may lead to unauthorised access to source code. This subsequently could lead to lose of intellectual property, exposure of sensitive workflows or application functionality contained in code.

Target State Solution

Summary 

The target state solution evaluates the following design requirements to provide the expected design principles for source code management.

Design Requirements  

The target state solution is required to meet the following requirements, as referenced under Dependences, Assumption and Constraints.

Requirement Implication to Design Principles
1. The scope and level of protection should be specific and appropriate to the asset at risk. Maintain tighter protection policies for public GIT repositories to address associated external threats
2. Security mechanisms must be pervasive, simple, scalable, and easy to manage. The security pattern maintains clear security principles to be applied for source code management
3. Assume context at your peril. Controls defined in this security pattern are used to identify and measure problems, limitations or issues
4. Devices and applications must communicate using open, secure protocols. Open and encrypted communication channels such as SSH/HTTPS are applied for interfaces to source code management services
5. All devices must be capable of maintaining their security policy on an un-trusted network. Source Code Management is protected against both external and internal threats
6. All people, processes, and technology must have declared and transparent levels of trust for any transaction to take place. Repository owners ensure responsible for appropriate policies are in place across contributes for security
7. Mutual trust assurance levels must be determinable. Utilise industry frameworks such as OpenID and OAuth2 for authentication and authorization
8. Authentication, authorization, and accountability must interoperate/exchange outside of your locus/area of control. Apply authentication and authorization for both internal, partner and public clients
9. Access to data should be controlled by security attributes of the data itself. Source Code MAnagement maintains security attributes as metadata for each Git repository
10. Data privacy (and security of any asset of sufficiently high value) requires a segregation of duties/privileges. Utilise secrets management for securing sensitive data or credential
11. By default, data must be appropriately secured when stored, in transit, and in use. Ensure protection of both Public and Private Git repositories

Solution Overview

The following represents the assets for source code management (SCM) across different trust domains and interactions between them.

Public and private Git repositories will have different considerations to security posture, and require separated security policies and configuration.

Private repositories may still be access by outsourced suppliers, business partners or temporary developers. SCM and primary GIT repositories may be sync or replicated to external locations for partners to cached versions of designated repositories.

Additional Notes

Design Principles  

The following design principles are applied to this pattern, based on the requirements.

  1. Never store secrets in code or configuration.
  2. Scan code for secrets and credentials during code commits
  3. Enable multi-factor authentication for contributors when available
  4. Validate any client or 3rd party applications requesting access
  5. Add security testing in your CI/CD pipelines to detect vulnerabilities
  6. Regularly rotate credentials such as SSH keys and access tokens used by developers.
  7. Maintain clearly separated trust boundaries and access policies between Public and Private GIT repositories

Actors

This pattern is involves following actors and entities

Actor Type Actor Description
System Administrator Global permissions to manage SCM servers and repositories, maintain system configuration and policy and define code owners for repositories.
Security Administrator Permissions to maintain security setting and services across SCM servers and repositories.
Repository Owner Complete administrative access (merge, push, pull, fork) across one or more public / private repositories and manages git workflows for contributors.
Repository Collaborator Trusted developers with read and write access to one or more repositories public / private repositories.
Restricted Collaborator 3rd party partners or temporary access provided for read and some limited write access to one or more repositories. Maybe restricted to specific designated master and or branches.
Anonymous Read only access to specific repositories designated as public.

Locations

This pattern is applied to any locations for assets being utilised

Location Type Location Description
Hosting location for Source Code Management Source Code Management and associated storage services maybe hosted internally or cached/sync into secondary locations for external partners or suppliers.
Access location to Source Code Management Source Code Management may be made available to either Internal, Partner and or Public locations.

Sequencing

The pattern is designed within the following sequences

Sequence Phase Sequence Description
Simple Git Workflow This pattern works from a standard workflow, with changes and commits against just the Master repository. This pattern assumes no branches within workflows to simplify the design.

Mapping Threats to Controls

The following provides a mapping of security threats to affected assets and the security control objectives required to mitigate them (further detailed in subsequent security pattern logical designs).  

Threat Event Affects Assets Mitigated by Security Controls
TE-09: Accidental leaks or sharing of information due to human error or mishandling Source Code GIT Repositories – Public
Source Code GIT Repositories - Private
Developer Workstations
AC-16: Security and Privacy Attributes
AT-02: Awareness Training
AU-13: Monitoring for Information Disclosure
IR-04: Incident Handling
IR-05: Incident Monitoring
IR-09: Information Spillage Response
SA-15: Development Process, Standards, and Tools
SA-11: Developer Testing and Evaluation
SA-16: Developer-provided Training
SC-03: Security Function Isolation
TE-14: Inadequate workflows or processes leading to flaws in deployment Source Code GIT Repositories – Public
Source Code GIT Repositories - Private
AT-02: Awareness Training
AU-10: Non-repudiation
PL-04: Rules of Behaviour
SA-03: System Development Life Cycle
SA-11: Developer Testing and Evaluation
SA-15: Development Process, Standards, and Tools
SC-35: External Malicious Code Identification
SI-02: Flaw Remediation
SI-05: Security Alerts, Advisories, and Directives
TE-16: Unintentional destruction of records through mismanaged data repositories or storage Source Code Management and Version Control CP-09: System Backup
CP-10: System Recovery and Reconstitution
SC-24: Fail in Known State
SC-28: Protection of Information at Rest
SC-32: System Partitioning
TE-29: Web application attacks or code injection attack Source Code Management and Version Control AU-02: Event Logging
AU-03: Content of Audit Records
AU-08: Time Stamps
CA-08: Penetration Testing
CM-02: Baseline Configuration
PM-16: Threat Awareness Program
RA-05: Vulnerability Monitoring and Scanning
SA-11: Developer Testing and Evaluation
SC-05: Denial of Service Protection
SC-08: Transmission Confidentiality and Integrity
SC-17: Public Key Infrastructure Certificates
TE-31: Unauthorized changes or manipulation of application functionality or code. Source Code GIT Repositories – Public
Source Code GIT Repositories - Private
CI/CD Pipelines
AC-06: Least Privilege
AC-13: Supervision and Review — Access Control
AU-02: Event Logging
AU-03: Content of Audit Records
AU-08: Time Stamps
AU-10: Non-repudiation
AU-16: Cross-organizational Audit Logging
PL-04: Rules of Behaviour
PM-12: Insider Threat Program
PS-03: Personnel Screening
PS-06: Access Agreements
SA-03: System Development Life Cycle
SA-10: Developer Configuration Management
SA-11: Developer Testing and Evaluation
SC-35: External Malicious Code Identification
SI-02: Flaw Remediation
TE-34: Violate isolation in multi-tenant environment Source Code Management and Version Control AC-06: Least Privilege
AC-22: Publicly Accessible Content
IA-02: Identification and Authentication (organizational Users)
IA-09: Service Identification and Authentication
IA-12: Identity Proofing
SC-14: Public Access Protections
SC-50: Software-enforced Separation and Policy Enforcement
TE-36: Unauthorized changes or manipulation of information data records Source Code Management and Version Control
Developer Workstations
AU-02: Event Logging
AU-03: Content of Audit Records
CM-10: Software Usage Restrictions
CP-09: System Backup
CP-10: System Recovery and Reconstitution
SC-28: Protection of Information at Rest
SI-03: Malicious Code Protection
TE-37: Compromise of confidential information or data breach Source Code GIT Repositories – Public AC-14: Permitted Actions Without Identification or Authentication
AC-20: Use of External Systems
AC-22: Publicly Accessible Content
IA-08: Identification and Authentication (non-organizational Users)
SA-06: Software Usage Restrictions
SA-09: External System Services
SC-14: Public Access Protections

Security Pattern

Pattern View: Source Code Management

Control list: Source Code Management (SCM) and Version Control

Control Objective Control Description
AC-02: Account Management Approve access based on roles assigned to individual and privileged users. Restrict permissions provided for global administrative access across repositories managed under SCM.
AC-03: Access Enforcement Enforce mandatory access controls for both public and private git repositories and restrict access to interfaces for SCM services.
AC-06: Least Privilege Default permissions enforce least privilege model for SCM
AC-22: Publicly Accessible Content Only allow external access to git repositories explicitly defined as 'public' by repository owner. Notify and prompt contributors during pre-commit where codebase and content is being made publicly accessible.
AU-02: Event Logging Enforce event logging across SCM services and system components. Forward and capture log events to centralised security logging and monitoring service.
AU-03: Content of Audit Records

Full audit logging must be enabled within SCM services including

  • Modification of system settings, parameters and/or configuration.

  • System start-up, shutdown, failures and restarts

  • Administrative activity including logon/logoff from privileged accounts.

  • Account creation, modification and deletion

  • Account lock-out (e.g. Three or more consecutive failed logon attempts)

  • Failed attempts to access storage services or system resources used for git repositories

AU-08: Time Stamps Ensure correct synchronisation of system time for time stamps within audit record generation, across all primary and replicated/sync repositories.
CA-08: Penetration Testing Conduct regular security testing across SCM services and system to identify potential flaws or breaches system confidentiality or integrity.
CM-02: Baseline Configuration

SCM software operates with approved and hardened security configuration baseline.

Source Code Management software is patched and up to date. Automate patching process where possible.

CM-10: Software Usage Restrictions Assess and review any 3rd party software packages, plugin modules or applications requiring integration within SCM services.
CP-09: System Backup Regularly backup and archive git repositories to alternate SCM services and secondary storage location, to protect against unintentional storage failures or intention data loss (malicious insider or ransomware)
CP-10: System Recovery and Reconstitution Regularly validate both data and system recoverability of backup and archived git repositories to primary SCM services.
IA-02: Identification and Authentication (organizational Users)

All contributors with read/write access to private git repositories and write access to public git repositories are uniquely identified.

No shared or generic account for users. Never let users share accounts/passwords used to access git repositories

IA-09: Service Identification and Authentication

All services or applications integrating with SCM are uniquely identified and authenticated.

Where supported, enforce mutual authentication between services.

IA-12: Identity Proofing Validate and verify user’s identity prior to issuing credentials or API Keys for accessing SCM system. This maybe through use of trusted identity management service or establish own identity proofing process.
PM-16: Threat Awareness Program Review SCM vendor for commitment to identifying vulnerabilities within their software and or participation in bug bounty programs
RA-05: Vulnerability Monitoring and Scanning Conduct regular vulnerability scanning and monitoring across SCM services and software.
SC-05: Denial of Service Protection Enforce protective measures to block or limit the effect of DOS attacks to SCM services and/or public git repositories
SC-08: Transmission Confidentiality and Integrity Encrypt all channels for access (SSH, HTTPS), including Rest API and webhooks.
SC-14: Public Access Protections Assign IP whitelisting to restrict access to private git repositories from untrusted network locations and all access via trusted remote access services.
SC-17: Public Key Infrastructure Certificates Enforce SSH mutual authentication and shorten session times to SCM services where possible.
SC-24: Fail in Known State Ensure and regularly test for recoverability of SCM services during potential failure of underlying platform and or dependant infrastructure.
SC-28: Protection of Information at Rest Encrypt all data at rest whenever applicable, including git repositories stored managed within database and or file systems.
SC-32: System Partitioning Enforce clear separation and isolation within SCM services for git repositories identified as public and those restricted as private.
SC-50: Software-enforced Separation and Policy Enforcement Maintain additional whitelisted access for CI/CD servers and only provide access required to pull codebase from repository and build it. Enforce explicit rules governing the installation of software including 3rd party modules, plugins or applications with access to SCM services.
SI-03: Malicious Code Protection SCM system and services have Endpoint Protection enabled for anti-malware and intrusion prevention.

Control list: Source Code GIT Repositories – Public

Control Objective Control Description
AC-03: Access Enforcement Enforce discretionary access restrictions for all contributors with full write permissions and require additional 2-factor-authentication on their accounts.
AC-06: Least Privilege Repository owners manage access to source code and data within principles of least privilege. Only give contributors access to the data they need to do their role.
AC-13: Supervision and Review — Access Control Security team periodically review developer practises and compliance with secure coding best practises.
AC-14: Permitted Actions Without Identification or Authentication Read access is permitted to anonymous users for codebase marked as public. Write access is not be permitted for anonymous users
AC-16: Security and Privacy Attributes Codebase maintains a SECURITY.MD file that provides general security-related information for the project including disclosure policy, security update policy and contact information for identified vulnerabilities or bug bounties.
AT-02: Awareness Training Security practices for code management are maintained in an easy-to-find document for both repository owners and contributors.
AU-02: Event Logging Enforce event logging across public git repositories, specifically for changes to repositories. Forward and capture log events to centralised security logging and monitoring service.
AU-03: Content of Audit Records

Audit logging is enabled for code changes and commits including

  • Source code check-in and check outs across master and dev branches.

  • Individual contributor changes and commits.

AU-08: Time Stamps Ensure correct synchronisation of system time for time stamps within audit record generation
AU-10: Non-repudiation Enforce PGP/GPG signed commits for contributors committing code to git repository.
AU-13: Monitoring for Information Disclosure Periodically scan codebases within git repositories for secrets that may have been committed. Trigger incident management process if secrets have been identified.
IA-08: Identification and Authentication (non-organizational Users) Uniquely identify access to public git repositories where possible, such as source location metadata (IP address).
IR-04: Incident Handling

Incident management processes cover the handling of

  • Invalidate, revoke or rotation credentials, tokens and passwords that were once public and or compromised.

  • purging sensitive files from your repository’s history.

IR-05: Incident Monitoring

Regularly scan and monitor for vulnerable code or commit that contain secrets.

Additionally, place honeypot secrets within sample code and monitor use of those secrets to detect potential incidents or breaches.

PL-04: Rules of Behaviour Repository owners outline clear guidelines to contributors and developers to coding practises and norms regarding git workflows and changes.
PM-12: Insider Threat Program Regularly monitor or peer review contributors at regular intervals to ensure compliance with coding best practises, workflows and level of access permissions granted remains appropriate.
PS-03: Personnel Screening Ensure documented process and plan for both onboard new hires and offboard exiting for any contributor with change or write access.
PS-06: Access Agreements Ensure clearly documented access agreements for any contributor with change or write access.
SA-11: Developer Testing and Evaluation Analyse and scan for secrets during code commits to identify any sensitive information such as password, API Keys or SSH private keys being placed into git repository.
SC-03: Security Function Isolation Developers utilise purpose-built secrets management service to prevent sensitive administrative, system or application credentials stored on workstation or git repositories.
SI-05: Security Alerts, Advisories, and Directives Monitor security advisories and feeds for updates in security best coding practises or hygiene. Regularly check repositories for appropriate security configurations.

Control list: Source Code GIT Repositories - Private

Control Objective Control Description
AC-03: Access Enforcement Enforce discretionary access restrictions for all contributors with full write permissions and require additional 2-factor-authentication on their accounts.
AC-06: Least Privilege Repository owners manage access to source code and data. Only give contributors access to the data they need to do their role. Manage fine grained permissions where available to control who can push commits to which branches.
AC-13: Supervision and Review — Access Control Security team periodically review developer practises and compliance with secure coding best practises.
AC-16: Security and Privacy Attributes Codebase maintains a SECURITY.MD file that provides general security-related information for the project including security update policy, details for secrets management vault(s) and or security hardening requirements.
AU-02: Event Logging Enforce event logging across git repositories. Forward and capture log events to external security logging and monitoring service.
AU-03: Content of Audit Records

Audit logging is enabled for code changes and commits including

  • Source code check-in and check outs across master and dev branches.

  • Individual contributor changes and commits.

  • Specific actions taken by contributors during changes including cloning, repository forking, branching, pull requests and or merging.

AU-08: Time Stamps Ensure correct synchronisation of system time for time stamps within audit record generation across any private git repositories including secondary remote or partner locations.
AU-10: Non-repudiation Enforce PGP/GPG signed commits for contributors committing code to git repository.
AU-13: Monitoring for Information Disclosure Periodically scan codebase within git repositories for secrets that may have been committed and. Trigger incident management process if secrets have been identified.
AU-16: Cross-organizational Audit Logging Capture audit logs from both primary git repositories and any replicated/sync secondary git repositories located in remote or partner sites.
IR-04: Incident Handling

Incident management processes covers the handling of

  • Invalidate, revoke or rotation credentials, tokens and passwords that were once public and or compromised.

  • purging sensitive files from your repository’s history.

IR-05: Incident Monitoring

Regularly scan and monitor for vulnerable code or commit that contain secrets.

Additionally, place honeypot secrets within sample code and monitor use of those secrets to detect potential incidents or breaches

PL-04: Rules of Behaviour Repository owners outline clear guidelines to contributors and developers to coding practises and norms regarding git workflows and changes.
PM-12: Insider Threat Program

Repository owners and security team monitor for unusual changes or behaviour across internal and partner teams.

Establish honeypots within specific codebase(s) to identify any potential insider threats attempting compromise confidentiality or integrity of repositories.

PS-03: Personnel Screening Ensure documented process and plan for both onboard new hires and offboard exiting for both internal staff, external 3rd party partners or temporary developers.
PS-06: Access Agreements Ensure clearly documented access agreements for any 3rd party partner, outsource provider or temporary developers with access to private git repositories.
SA-11: Developer Testing and Evaluation Analyse and scan for secrets during code commits to identify any sensitive information such as password, API Keys or SSH private keys being placed into git repository.
SI-05: Security Alerts, Advisories, and Directives Monitor security advisories and feeds for updates in security best coding practises or hygiene. Regularly check repositories for appropriate security configurations.

Control list: Developer Workstations

Control Objective Control Description
AC-16: Security and Privacy Attributes Developers and contributors maintain SECURITY.MD files for code bases that they actively work on or make changes.
AT-02: Awareness Training Provide awareness training to all contributors and developers for security hygiene and how to manage vulnerable components, configuration mistakes or leaked secrets.
CM-10: Software Usage Restrictions Developers utilise approved software and tooling for code development to avoid potential data leakage or compromise of source code.
IR-09: Information Spillage Response

Developers are trained and prepared for processes involved leaked credentials or secrets, and steps required to

invalidate credentials, tokens and passwords that were compromised

SA-15: Development Process, Standards, and Tools Developers operate within provided guidelines for development practises and behaviours. Developers periodically refresh and rotate SSH Keys or credentials used for accessing SCM.
SA-16: Developer-provided Training Developer education require best practises for secure coding (such as OWASP Secure Coding Practises). Developers maintain regular code check-ins and clear documentation for security related changes or features in codebase.
SC-03: Security Function Isolation Developers utilise secrets management services to prevent sensitive information or credentials associated to codebase being stored on workstation.
SC-28: Protection of Information at Rest Developer workstation, laptops or devices with access to git repositories are properly secured including encryption at rest.
SI-03: Malicious Code Protection Developer workstation have endpoint protection enabled for anti-malware and intrusion prevention.

Control list: CI/CD Pipelines

Control Objective Control Description
AC-13: Supervision and Review — Access Control Periodically review developer practises and compliance with standard workflows.
AU-02: Event Logging Enforce event logging across CI/CD pipelines. Forward and capture log events to centralised security logging and monitoring service.
AU-03: Content of Audit Records

Audit logging is enabled for changes to workflows or pipelines regarding code development including

  • Modification of system settings, parameters and/or configuration.

  • Workflow creation, modification and deletion

  • Logon to and logoff from privileged accounts

AU-08: Time Stamps Ensure correct synchronisation of system time for time stamps within audit record generation across tooling.
AU-10: Non-repudiation Ensure digitally signed artefacts for approvals in workflows and stage gates, particular for security related functions or testing.
PL-04: Rules of Behaviour Standardise and automate workflows where ever possible to enforce rules of behaviour for software development practises
PM-12: Insider Threat Program Monitor for deviations or unauthorised changes to developer workflows or CI/CD pipeline.
RA-10: Threat Hunting Identified vulnerabilities trigger either failed pull requests or failed build. Block vulnerable code from being merged and alert contributors of findings.
SA-03: System Development Life Cycle Ensure secure development lifecycle and workflows from Blueprint to Execution. Apply tighter access and change restrictions to higher level production environments.
SA-11: Developer Testing and Evaluation Apply security testing within CI/CD pipeline including peer review, static code analysis and or dynamic code analysis/sandboxing.
SC-35: External Malicious Code Identification

Scan for external dependencies within codebase for potential vulnerabilities or malicious code.

Block pull requests from being merged for new vulnerabilities identified and alert contributors of findings.

SI-02: Flaw Remediation Remediated vulnerabilities committed within codebase is clearly documented and tracked to prevent re-introduction during any code rollback or new branches.

Appendix A – References

Please see below links to external sites for further reading

Appendix B - Disclosure Notice

This document is published as independent research only and is without warrenty. It does not represent any publication from National Institute of Standards and Technology (NIST) or other associated US government entities.