Happy holidays 🎄 (Vibe) Code safely 🎁

GitArmor: take control of where your code lives

Securing the source control layer of modern software development is a critical aspect of supply chain defense. Even when developers follow secure coding practices, misconfigurations at the repository or organization level can create attack surfaces that adversaries exploit to insert malicious code, tamper with build processes, or compromise automation workflows.

Most of the times these settings are either hidden or not enabled by default. GitArmor gives visibility into the security controls that must or should be enabled, and allows repository and organization owners to create custom repeatable policies to verify those settings are not tampered with. 

The project can be found at  https://github.com/dcodx/gitarmor

This post discusses GitArmor’s threat modeling foundations, its policy constructs, and demonstrates how policies can be used to mitigate real supply-chain attacks.

We also announce the latest release and share practical examples you can adopt.

Threat Model

GitArmor comes with  repository and organization threat models, to create the linkage between configuration checks and real threats. 

Rather than reporting generic “pass/fail” results, GitArmor enriches failed checks with links to relevant threat documentation – including references from SLSA.dev and the MS DevOps Threat Matrix – so the associated risk is contextualized, and each threat is presented with detailed information like the example below.

 

THREAT: Malicious actions in workflows configuration could be executed to compromise the supply chain

A malicious actor could compromise an action used by the repository to execute malicious code, exfiltrate secrets or data and compromise the supply chain.

Security controls

  • Restrict the actions that can be used in the repository
  • Restrict the actions that can be used in the repository to GitHub owned actions
  • Restrict the actions that can be used in the repository to a list of safe actions verified by security engineers and trusted developers
  • Pin the version of the actions used in the repository to a specific hash

Gitarmor policy configuration

allowed_actions:
  use_pinning: true
  permission: selected
  selected:
    github_owned_allowed: true
    verified_allowed: false
    patterns_allowed:
      - "trused_author/*"
      - "dcodx/*"
 

SLSA.dev threats

MS DevOps threat matrix

What this gives you

Automating this checks allow organizations to take full control of how repositories are configured, at scale. You can run these checks on all repos in the same organization. Some examples are listed here. 

Compliance Standard / Control

Control / Requirement

How GitArmor Helps

ISO 27001:2022 – Annex A 5.15 Access Control

Ensure access is restricted based on least privilege and documented policy

GitArmor policies enforce least-privilege practices (e.g., restrict workflow permissions and limit admin privileges) and flag misconfigurations that violate access governance principles. 

ISO 27001:2022 – Annex A 12.1 Operational Procedures & Change Management

Ensure secure configuration and controlled changes are applied

GitArmor enables codified, repeatable configuration checks for repositories and org settings, supporting documented change control processes and consistency. 

ISO 27001:2022 – Annex A 8.4 Secure Development and Change Management

Apply secure configuration and controls for development processes

GitArmor enforces secure repository settings (e.g., branch protection), helping ensure unauthorized changes cannot bypass review or break stability. 

SOC 2 – Common Criteria 8.1 Change Management

Demonstrate that changes to IT systems and software are authorized, documented, and tested in a controlled manner

GitArmor’s automated checks and versioned policy enforcement provide documented evidence and audit logs showing consistent configuration validation across repos. 

SOC 2 – Logical Access Controls

Restrict system access based on roles and least privilege

By validating permission settings (e.g., action permissions, admin roles), GitArmor ensures access controls align with SOC 2 expectations for logical access governance. 

NIST CSF – PR.AC (Access Control)

Ensure access is limited to authorized users and roles

GitArmor policies enforce repo and org-level controls that demonstrate least privilege and role-based access alignment with NIST CSF principles. 

NIST CSF – PR.IP (Protective Technology & Configuration Management)

Deploy protective technologies and secure configurations

GitArmor automates secure configuration checks and produces audit output that supports evidence of protective technology enforcement. 

Software Supply Chain Security (SLSA Source Integrity Controls)

Verify source integrity and prevent unauthorized code change injection

GitArmor’s threat-linked checks (e.g., branch protection, restricted workflows) align with source integrity controls recommended by SLSA to mitigate supply chain tampering risks.  

GitArmor also supports the technical foundations of supply chain security, which is central to both NIS2 and CRA.

 

What this does not give you

GitArmor is not a compliance tool and it does not guarantee compliance with a full standard or regulation.

GitArmor’s value is in automating technical configuration governance, not in covering full policy, process, or vulnerability lifecycle requirements mandated by regulatory texts.

What’s new

The latest published release, v1.0.1 (December 2025), consolidates organizational and repository policy checks and enhances reporting capabilities.  

Do you want to contribute to the project? Read our CONTRIBUTING.md guidelines and oper a PR.

Related Posts

Tagged , , ,