DOCUMENTATION

How Normos Works

The Normos Sleuth Engine runs 21 deterministic detectors across five domains — Identity, Code, Machine Identity, Access Control, and Supply Chain — producing forensic, auditable evidence of your compliance posture. No guesswork. No sampling. Proof.

26Detectors
5Domains
346/346Tests Passing
2Frameworks

The Sleuth Engine

The Sleuth Engine is a deterministic, TypeScript-native analysis engine. It connects to your systems via authorised integrations, runs a fixed set of detectors against observed state, and produces structured findings — each mapped to specific compliance controls.

Deterministic means the same inputs always produce the same findings. This is a deliberate architectural choice: compliance evidence must be reproducible, auditable, and legally defensible. Probabilistic or AI-generated findings are not.

Deterministic

Same inputs, same outputs. Every finding is reproducible and verifiable.

Zero Raw Data

Only findings are persisted. No source code, credentials, or business data stored.

Audit-First

Every finding carries explicit control references, subject IDs, and timestamps.

The Sleuth Fleet

21 detectors across 5 domains. Each detector monitors a specific control boundary, produces structured findings, and maps explicitly to ISO 27001 and SOC 2 requirements.

IDENTITY DOMAIN

Identity Sleuths

Who has access — and should they?

Identity is the most common attack surface in modern SaaS environments. The Identity Sleuths continuously monitor your user population for access anomalies, lifecycle failures, and service account governance violations that manual reviews consistently miss.

ISO 27001:A.5.16A.8.2A.8.5SOC 2:CC6.1CC6.2CC6.3

MFA Coverage

Identifies user accounts operating without multi-factor authentication. Covers all account types including administrative and developer accounts.

Risk: Accounts without MFA are trivially compromised via credential stuffing, phishing, or password reuse. MFA is a baseline control for every compliance framework.
ISO A.8.5SOC 2 CC6.1

Dormant Account Detection

Identifies user accounts that have not been active within your defined window. Dormant accounts are a persistent attack vector — they retain access but receive no security scrutiny.

Risk: Attackers routinely target dormant accounts precisely because they are forgotten. A single compromised dormant account can grant persistent, undetected access.
ISO A.5.16SOC 2 CC6.2

Service Account Governance

Detects service accounts that are misconfigured or operating outside your defined service account policy. Distinguishes between human and non-human identities.

Risk: Service accounts are frequently over-permissioned and rarely reviewed. They represent a high-value target because they often have broad, persistent access.
ISO A.8.2SOC 2 CC6.3

CODE DOMAIN

Code Sleuths

Is your development process trustworthy?

Your source code pipeline is a critical control boundary. The Code Sleuths analyse your GitHub repositories for process failures, bypass events, and review integrity issues that undermine the trustworthiness of your deployment chain.

ISO 27001:A.8.25A.8.32A.5.3SOC 2:CC7.1CC8.1CC9.2

PR Coverage

Measures the proportion of commits reaching your main branch via an approved pull request process. Identifies direct pushes and unreviewed merges.

Risk: Unreviewed code reaching production is a control failure. It creates an unauditable pathway for both accidental and malicious changes.
ISO A.8.25SOC 2 CC8.1

Branch Protection Bypass

Detects events where branch protection rules were bypassed — including administrator overrides, forced pushes, and protection rule modifications.

Risk: Branch protection bypass events should be exceptional and always explainable. Unexplained bypasses are a serious audit finding and a potential insider threat signal.
ISO A.8.32SOC 2 CC7.1

Reviewer Independence

Verifies that pull request approvals are granted by reviewers independent of the code author. Detects self-approval patterns and insufficient reviewer separation.

Risk: Self-approval or approval by a direct collaborator undermines the entire purpose of code review as a control. Auditors expect genuine independence.
ISO A.5.3SOC 2 CC8.1

Commit Approval Coverage

Validates that commits merging to protected branches carry the required approval signatures. Identifies commits that bypassed the approval gate.

Risk: Unapproved commits reaching protected branches represent a direct control failure against your change management policy.
ISO A.8.25SOC 2 CC8.1

Secrets in Code

Scans for credential patterns, API keys, tokens, and other secrets committed to your repositories. Covers current state and detects patterns indicative of historical exposure.

Risk: A single committed secret can expose your entire infrastructure. Secrets in code are trivially discoverable by anyone with repository access — including future employees.
ISO A.8.10SOC 2 CC6.1

Branch Protection Rules

Audits the configuration of branch protection rules across your repositories. Identifies repositories with missing, weakened, or misconfigured protection settings.

Risk: Repositories without strong branch protection have no enforceable change control. A single misconfigured repository can undermine your entire code governance posture.
ISO A.8.32SOC 2 CC7.1

Review Collusion Risk

NORMOS ORIGINAL

Identifies review patterns where the same individuals consistently review each other's code, creating a closed loop that compromises the independence of the review process.

Risk: Collusive review patterns are invisible to standard access reviews but represent a systemic control failure. They create conditions where errors or malicious changes pass unchallenged.
ISO A.5.3SOC 2 CC9.2

DRIFT DOMAIN — PHASE 2

Drift Sleuths

Is your infrastructure staying compliant? (AWS integration — Phase 2)

Compliance is not a point-in-time state — it drifts. The Drift Sleuths continuously monitor your cloud and infrastructure configuration for deviations from your baseline security posture, catching misconfiguration before auditors do.

ISO 27001:A.8.7A.8.20A.8.23SOC 2:CC6.6CC6.7CC7.2

Encryption at Rest

Verifies that data stores and volumes have encryption at rest enabled and correctly configured. Identifies unencrypted resources across your connected infrastructure.

Risk: Unencrypted data at rest is a critical finding in every compliance framework. It represents direct exposure in the event of physical or logical storage compromise.
ISO A.8.24SOC 2 CC6.7

IAM Wildcard Detection

Identifies IAM policies and role bindings that use wildcard permissions, granting broader access than intended or required by the principle of least privilege.

Risk: Wildcard IAM permissions are a systemic over-privilege failure. They negate the entire purpose of role-based access control and are a consistent audit finding.
ISO A.8.2SOC 2 CC6.3

Logging Coverage

Audits whether logging and audit trails are enabled across your connected systems. Identifies resources where logging has been disabled or was never configured.

Risk: Disabled logging is both a control failure and a forensic liability. Without logs, you cannot investigate incidents, demonstrate compliance, or reconstruct events for auditors.
ISO A.8.15SOC 2 CC7.2

Public Resource Exposure

Detects resources that are unintentionally exposed to the public internet. Covers storage buckets, databases, APIs, and compute resources with unrestricted public access.

Risk: Publicly exposed resources are among the most common causes of data breaches. Misconfiguration is frequently invisible to manual review and requires continuous automated detection.
ISO A.8.20SOC 2 CC6.6

Open Security Groups

Identifies network security groups and firewall rules with overly permissive ingress or egress rules — including unrestricted 0.0.0.0/0 rules on sensitive ports.

Risk: Open security groups are a direct network exposure. They widen the attack surface beyond what any application or access control can compensate for.
ISO A.8.20SOC 2 CC6.6

ACCESS CONTROL DOMAIN

Access Control Sleuths

Are permissions limited to what is actually needed?

Privilege creep is silent and cumulative. The Access Control Sleuths continuously audit permission levels across your GitHub organisation — detecting excessive admin accounts, ungoverned outside collaborators, and over-privileged teams before auditors do.

ISO 27001:A.8.2A.5.15SOC 2:CC6.3

Organisation Owner Count

Detects organisations with more owner-level accounts than the policy maximum. Organisation owners have unrestricted access to all repositories, settings, and billing.

Risk: Excessive org owners means excessive blast radius if any one account is compromised. Auditors expect the number of privileged accounts to be demonstrably minimal.
ISO A.8.2SOC 2 CC6.3

Outside Collaborator Governance

Identifies outside collaborators with write or admin access to repositories. Outside collaborators bypass normal organisation membership controls and are a consistent audit finding.

Risk: Outside collaborators are ungoverned privileged access. They are not subject to your organisation's access review process and represent an uncontrolled external access pathway.
ISO A.8.2SOC 2 CC6.3

Team Excessive Permissions

Detects teams with admin-level permissions on repositories where write access is sufficient. Team admin grants all members the ability to override branch protection and modify repository settings.

Risk: Team admin access undermines every other code domain control. A team with admin rights can disable branch protection, bypassing all PR and review enforcement.
ISO A.8.2SOC 2 CC6.3

Repository Admin Count

Identifies repositories with more admin-level collaborators than the policy maximum. Repository admins can override branch protection and all access controls.

Risk: Excessive repository admins create multiple points of control failure. Any one admin can disable the security controls that protect your code pipeline.
ISO A.8.2SOC 2 CC6.3

SUPPLY CHAIN DOMAIN

Supply Chain Sleuths

Is your software supply chain trustworthy?

Your CI/CD pipeline and GitHub Actions workflow are part of your attack surface. The Supply Chain Sleuths continuously audit action pinning, publisher verification, and secret scanning alerts — catching supply chain risk before it becomes a breach or an audit finding.

ISO 27001:A.8.30A.5.19SOC 2:CC8.1CC9.2

Unpinned Action Version

Identifies GitHub Actions workflows that reference actions by mutable tag (e.g. @v4) rather than an immutable commit SHA. Mutable tags can be silently redirected to malicious code.

Risk: An unpinned action is a supply chain injection vector. A compromised upstream action tag could execute arbitrary code in your CI/CD pipeline with full repository access.
ISO A.8.30SOC 2 CC8.1

Unverified Action Publisher

Detects GitHub Actions from publishers who have not completed GitHub's verified creator programme. Unverified publishers have not been subject to GitHub's identity and security review.

Risk: Actions from unverified publishers represent an unassured third-party code dependency executing inside your CI/CD pipeline. There is no baseline assurance of the publisher's security posture.
ISO A.5.19SOC 2 CC9.2

Secret Scanning Alert

Surfaces open GitHub Secret Scanning alerts — detected credentials that have not been remediated. Operates in zero-footprint mode: no credential values are read or stored, only alert metadata.

Risk: An open secret scanning alert means a live credential is committed to your codebase. Every minute it remains unrevoked is a minute of active exposure.
ISO A.8.12SOC 2 CC6.7

VENDOR DOMAIN — PHASE 2

Vendor Sleuths

Are your third parties staying compliant? (Certification body integration — Phase 2)

Your compliance posture is only as strong as your weakest vendor. The Vendor Sleuths monitor the currency and integrity of third-party compliance evidence — continuously, not just at contract renewal.

ISO 27001:A.5.19A.5.20A.5.21SOC 2:CC9.2

Expired Report Detection

Identifies vendors whose SOC 2, ISO 27001, or other compliance reports have passed their validity period. Tracks report expiry across your entire vendor population.

Risk: An expired compliance report provides no assurance. Operating with expired vendor evidence is a direct audit finding and a real risk — you have no current basis for trusting that vendor's controls.
ISO A.5.19SOC 2 CC9.2

Material Weakness Detection

Analyses vendor compliance reports for disclosed material weaknesses, exceptions, and qualified opinions. Surfaces adverse findings that require your attention and response.

Risk: A vendor's material weakness is your risk. Auditors will ask whether you identified and responded to adverse findings in your vendors' reports.
ISO A.5.20SOC 2 CC9.2

Missing Report Detection

Identifies vendors in scope for your compliance programme who have not provided current compliance evidence. Surfaces gaps in your third-party assurance coverage.

Risk: A vendor without a compliance report is an unassured risk. You cannot make an informed trust decision without evidence, and auditors expect comprehensive coverage.
ISO A.5.19SOC 2 CC9.2

Evidence Freshness Decay

NORMOS ORIGINAL

Monitors the age and relevance of vendor compliance evidence on a continuous basis. Identifies evidence that is technically within its validity period but approaching staleness — before it expires.

Risk: Point-in-time expiry checks miss the gradual decay of assurance confidence. Evidence freshness monitoring ensures you are never caught with a compliance gap at audit time.
ISO A.5.21SOC 2 CC9.2

Severity Levels

Severity is assigned by policy, not by detectors. Detectors observe conditions — policy determines impact. This separation ensures severity is consistent, auditable, and adjustable without changing detection logic.

CRITICAL

Severe exposure, likely exploitability, or systemic control failure. Requires immediate remediation.

HIGH

Significant control failure requiring prompt remediation within your defined SLA.

MEDIUM

Moderate risk that should be reviewed and remediated in a reasonable timeframe.

LOW

Informational or low-risk issues. Does not require immediate action but should be tracked.

Getting Started

01

Connect GitHub

Authorise Normos via GitHub OAuth. We request four scopes: read:user, read:org, repo, and admin:org. All are read-only. No write access. No code storage.

admin:org is required solely to identify members without MFA enabled — it uses GitHub's filter=2fa_disabled API endpoint and reads no other organisation data. OAuth tokens are encrypted at rest using AES-256-GCM. We never store your source code, commit content, or any raw repository data.

02

Run Your First Scan

Scans run automatically every day at 02:00 UTC — no manual action required. You can also trigger an on-demand scan from your Security Command Centre at any time. The Sleuth Engine™ runs all 21 detectors and returns findings within seconds.

Scans are deterministic — the same inputs always produce the same findings. Every scan is timestamped, hash-chained, and logged to your audit trail. You receive an email with your forensic hash reference after every scan.

03

Review Your Findings

Findings are presented by severity — Critical first. Each finding includes full forensic detail: what was detected, why it matters, and the evidence references behind it.

Findings map explicitly to ISO 27001 and SOC 2 controls. Your auditor can trace every finding to a specific control requirement.

04

Invite Your Auditor

Generate a token-gated auditor link from your dashboard. Your auditor gets a clean, read-only view of your findings and evidence — no account required.

Auditor access is scoped, time-limited, and logged. Every auditor action is recorded in your audit trail.

05

Generate Evidence Package

Download a branded PDF evidence package mapped to ISO 27001 or SOC 2. Share it directly with your auditor or attach it to your audit submission.

Evidence packages include your findings, control mappings, scan metadata, and timestamps. Ready for auditor submission.

Evidence & Assurance

PDF Evidence Packages

LIVE

Branded PDF reports pre-mapped to ISO 27001 or SOC 2. Each package includes your findings, control mappings, scan metadata, and timestamps. Ready for direct auditor submission.

Token-Gated Auditor Portal

LIVE

Generate a secure, read-only link for your auditor. No Normos account required. Access is scoped, time-limited, and every auditor action is recorded in your audit trail.

Signed Assurance Letters

LIVE

A fully automated formal letter generated by Normos on every scan, summarising your compliance posture based on cryptographic scan evidence. Designed to carry evidential weight with auditors beyond a self-assessment. Included in all tiers.

Immutable Audit Trail

LIVE

Every platform action — scans, findings, resolutions, auditor access — is recorded in an append-only audit log with user, organisation, timestamp, and action details.

Azure SQL Ledger Notarisation

ROADMAP

Phase 1: Every scan generates a SHA-256 forensic hash chain — a tamper-evident fingerprint of all findings printed on every evidence package (NRM-XXXXXXXX-V1 format). Phase 2: Azure SQL Ledger with ML-DSA post-quantum signing makes the chain externally immutable — not even Normos can alter it.

Security & Compliance Posture

For information on Normos's own security controls, penetration testing roadmap, subprocessors, and compliance status — including our CREST pen test timeline and SOC 2 Type II roadmap — visit our Trust Centre →

Frequently Asked Questions

Is my source code ever stored?

No. We never store raw source code, commit content, pull request bodies, or any raw repository data. The Sleuth Engine™ analyses metadata — not content — and only the resulting findings are persisted.

How often does Normos scan?

Normos runs an automated scan of your connected systems every day at 02:00 UTC — no manual action required. You will receive an email with your findings summary and forensic hash reference each morning. You can also trigger an on-demand scan at any time from your Security Command Centre.

What GitHub permissions does Normos require?

Normos requests four GitHub OAuth scopes: read:user (your profile), read:org (organisation membership and teams), repo (repositories, branch protection, pull requests, and workflow files), and admin:org (required solely to identify members without MFA — uses GitHub's filter=2fa_disabled endpoint). All scopes are used in read-only mode. We request no write permissions and cannot modify your repositories or organisation settings.

Which compliance frameworks do you support?

Phase 1 covers ISO 27001:2022 and SOC 2 (Trust Services Criteria). Phase 2 will add ISO 42001 AI Governance, Cyber Essentials, and additional frameworks.

How do findings map to audit controls?

Every finding carries explicit control references — ISO 27001 Annex A controls and SOC 2 Trust Services Criteria. Your evidence package presents findings pre-mapped to the relevant framework.

What is a Signed Assurance Letter?

A Signed Assurance Letter is a formal document issued by Normos that summarises your compliance posture based on scan evidence. It is designed to be presented to auditors and carries evidential weight beyond a self-assessment.

How do I add my auditor?

From your Security Command Centre, select Invite Auditor. Enter their email address and Normos will send them a branded invitation with a secure, token-gated link to your evidence portal. No Normos account required for auditors.

Has Normos been penetration tested?

A professional penetration test by a CREST-accredited firm is planned before our first paying customer. Current security status: 346/346 tests passed across our full security test suite. See our Trust Centre for full details.

READY TO START

Forensic Proof. Automated.

Join the Normos Pilot Programme. Free access in exchange for monthly product feedback. Five spots available.

Apply for Pilot Access