Security Pattern – Source Code Management

Overview

This security pattern outlines controls for protecting company-developed source code from external and internal threats. Source code management is used to track modifications to a repository, maintain a history of changes to a codebase, and resolve conflicts when merging updates from multiple contributors.

Git repositories, as a distributed source code management system, have become the de facto solution for most organisations, replacing 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

With higher frequencies of changes from multiple contributors, identifying and tracking vulnerable code across source code branches has become more complex.
Repositories exposed to the public for information sharing require greater consideration than private repositories. This is due to the potential for leaking confidential information, the need to protect intellectual property, and the risk of undiscovered vulnerabilities within application code.
Secrets or sensitive information can be inadvertently committed to repositories and made accessible to anyone with read access. This is particularly problematic for public repositories accessible to anyone.
Various developers require direct access permissions across primary, secondary, or local repositories. These developers could be internal staff, partners, or public contributors.

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 3^rd 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

Software artefact management - This should be considered within separate security patterns.
CI/CD Tooling – Underlying tooling used for executing CI/CD Pipelines is considered separate security pattern
Underlying infrastructure - This should be considered within separate security patterns.
Collaboration Tooling - Protection of ChatOps and Collaboration tooling integrating with these assets. This should be considered within separate security patterns.
Remote Access – End user remote access connectivity facilitating access to Source Code Management assets. This should be considered within separate security patterns.

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, or access tokens. These can be accidentally checked into 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 the target system. Security flaws within code can be introduced at any stage of the software development lifecycle and workflows. Remediated flaws can also be reintroduced due to poor code management practices 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, resulting in unavailability or inaccessibility of source code.
TE-29: Web application attacks or code injection attack	Software used to manage and administer source code repositories may be vulnerable to web application attacks against exposed API interfaces, manipulation of webhooks, or manipulation of command parameters/arguments.
TE-31: Unauthorised 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 exploit those weaknesses within the target application, system, or business processes.
TE-34: Violate isolation in multi-tenant environment	Tenant 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: Unauthorised changes or manipulation of information data records	Unauthorised changes to git repositories through malicious insider actions or ransomware could intentionally encrypt or remove git repositories, causing unavailability or inaccessibility of 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 third-party applications accessing source code repositories, leading to unauthorised access to source code. This could subsequently result in loss 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 their interactions.

Public and private Git repositories have different security considerations and require separate security policies and configurations.

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

Additional Notes

Connectivity to SCM for internal contributors is the same partner or public.
Establish high levels of trust for contributors through identity and access management.
- All owners and contributors with access remain authenticated through a trusted identity provider.
- Validate the identity of all applications access SCM and where possible establish mutual trust.
SCM ensures the integrity and non-repudiation for any source code changes (incl commits, push, pull, branches or merges)
- Different interfaces exposed by SCM (Command Line, Rest API interfaces, Webhooks) are protected regardless of source location of contributors (internal, partner, public)
- Access controls are considered against different types of developers for cloning, repository forking, branching, pull requests and merging
Sequencing considers different access requirements during Development, Testing and Prod release phases.
All Git workflows allow for secrets to be identified and or blocked during commits to git repositories.
Repository owners ensure responsible for appropriate policies are in place across contributes for security.

Design Principles

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

Never store secrets in code or configuration.
Scan code for secrets and credentials during code commits
Enable multi-factor authentication for contributors when available
Validate any client or 3rd party applications requesting access
Add security testing in your CI/CD pipelines to detect vulnerabilities
Regularly rotate credentials such as SSH keys and access tokens used by developers.
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 3^rd 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 3^rd 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 3^rd party partners or temporary developers.
PS-06: Access Agreements	Ensure clearly documented access agreements for any 3^rd 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.