aiir

Repository on GitHub, which provides public git repositories with URLs: https://github.com/invariant-systems-ai/aiir

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The repository includes all interim commits between releases. Development happens on feature branches with pull requests reviewed before merging to main. The full commit history is publicly visible, not just tagged releases.

Repository on GitHub, which uses git. git is distributed.

Every release has a unique SemVer identifier (e.g. 1.2.4). The version is the single source of truth in aiir/init.py and a CI job (version-check) verifies all version-bearing files match on every push. 23 distinct versions released to date.

Every release is identified by a git tag matching vX.Y.Z (e.g. v1.2.4). The Publish workflow triggers exclusively on tag pushes matching 'v[0-9]+.[0-9]+.[0-9]+'. 23 tags exist in the repository.

Non-trivial release notes file in repository: https://github.com/invariant-systems-ai/aiir/blob/main/CHANGELOG.md. Uses Keep a Changelog format with Added/Changed/Fixed/Security sections for every release. Not raw git log output.

N/A. No CVEs have been assigned against the project. Zero publicly known vulnerabilities exist. If a CVE were assigned, SECURITY.md commits to fixing Critical/High within 7 days and documenting the fix in CHANGELOG.md release notes.

Bug reports are submitted via GitHub Issues using a structured YAML template: https://github.com/invariant-systems-ai/aiir/issues/new?template=bug_report.yml. Feature requests use a separate template. CONTRIBUTING.md links both templates. SECURITY.md provides a private channel for vulnerability reports.

The project uses GitHub Issues as its issue tracker: https://github.com/invariant-systems-ai/aiir/issues. Structured templates are provided for bug reports (bug_report.yml) and feature requests (feature_request.yml).

The project is actively maintained with a single primary developer who monitors and responds to all issues. The project launched in 2026; all issues to date have been acknowledged within 24 hours.

Feature requests are submitted via GitHub Issues (feature_request.yml template) and are responded to promptly. The project is actively maintained and all enhancement requests have received responses.

GitHub Issues provides a publicly searchable archive of all bug reports and responses: https://github.com/invariant-systems-ai/aiir/issues?q=is%3Aissue

SECURITY.md documents the full vulnerability reporting process: email address, required information (description, repro steps, affected versions, severity, suggested fix), response timelines (24h ack, 48h triage, 7d fix for Critical/High), scope, and out-of-scope items. https://github.com/invariant-systems-ai/aiir/blob/main/SECURITY.md

Private vulnerability reports are accepted via email to noah@invariantsystems.io with subject prefix "[VULN] aiir:". SECURITY.md explicitly states: "Do NOT open a public GitHub issue for security vulnerabilities." https://github.com/invariant-systems-ai/aiir/blob/main/SECURITY.md#reporting-a-vulnerability

SECURITY.md commits to acknowledgment within 24 hours and initial triage within 48 hours — well under the 14-day requirement. No vulnerability reports have been received in the last 6 months; the project has no known vulnerabilities.

AIIR is a pure-Python package built with Hatchling (pyproject.toml declares build-backend = "hatchling.build"). "pip install ." builds from source automatically. CI builds and installs the wheel on every push and verifies entry points work (ci.yml "package" job).

Uses standard Python packaging tools: pyproject.toml (PEP 621), Hatchling build backend, pip for installation, pytest for testing. All widely-used standard Python ecosystem tools.

All build tools are FLOSS: Python (PSF License), Hatchling (MIT), pip (MIT), pytest (MIT). The project itself has zero runtime dependencies. The entire build and test pipeline uses only open-source tools.

1,680+ automated tests in tests/ directory, publicly available under Apache-2.0. Tests run on every push via GitHub Actions (ci.yml). Suite includes unit, integration, security, end-to-end, property-based fuzz (Hypothesis), and mutation tests. Instructions: "python -m pytest tests/ -q" per CONTRIBUTING.md. https://github.com/invariant-systems-ai/aiir/blob/main/.github/workflows/ci.yml

Tests are invoked via the standard Python test command: "python -m pytest tests/ -q". Configured in pyproject.toml [tool.pytest.ini_options]. Also available via nox sessions ("nox -s test"). Documented in CONTRIBUTING.md Quick Start section.

The project enforces 100% line + branch coverage via "coverage report --fail-under=100" in CI. Additionally, 52 property-based fuzz tests (Hypothesis) generate ~53,000 adversarial inputs per run, and mutation testing (mutmut) verifies test effectiveness by ensuring mutants are killed.

GitHub Actions CI runs on every push and pull request to main. Full Python version matrix (3.9, 3.10, 3.11, 3.12, 3.13) on Linux, plus Windows and macOS. Three required status checks gate merges: ci-ok, quality-ok, security-ok. https://github.com/invariant-systems-ai/aiir/blob/main/.github/workflows/ci.yml

CONTRIBUTING.md Pull Request Process step 2: "Write tests for any new functionality." Code Standards section: "Test everything. We maintain 1680+ tests across unit, integration, security, and fuzz suites. 100% coverage enforced." CI rejects PRs that reduce coverage below 100%. https://github.com/invariant-systems-ai/aiir/blob/main/CONTRIBUTING.md

Every recent release added tests alongside new functionality. v1.2.2 added 18 transport attestation tests, 14 coverage gap tests, and DAG binding tests. v1.2.0 added 62 new tests across 14 test classes. v1.2.3 added markdown lint enforcement tests. CHANGELOG.md documents test additions for each release. https://github.com/invariant-systems-ai/aiir/blob/main/CHANGELOG.md

CONTRIBUTING.md Pull Request Process step 2 states: "Write tests for any new functionality." The Code Standards section states: "Test everything. We maintain 1680+ tests… 100% coverage enforced." CI enforces --fail-under=100, making untested code impossible to merge. https://github.com/invariant-systems-ai/aiir/blob/main/CONTRIBUTING.md#pull-request-process

Multiple linters enforced in CI on every push: Ruff (lint + format), mypy (static type checking), Bandit (security linter), Semgrep (taint-tracking SAST), CodeQL (semantic analysis), Hadolint (Dockerfile lint), markdownlint, actionlint (workflow YAML). Workflows: security.yml, quality.yml, codeql.yml.

All linter warnings must be resolved for CI to pass. Three required status checks (ci-ok, quality-ok, security-ok) gate all merges. Zero unresolved warnings in the current codebase. Any new warning introduced by a PR causes CI failure and blocks merge.

Ruff enforces default rules. Mypy configured with warn_return_any, warn_unused_configs, check_untyped_defs, no_implicit_optional, warn_redundant_casts, warn_unused_ignores. Bandit fails on MEDIUM severity and above (-ll). Coverage fails under 100%. Semgrep runs 2,500+ Python security rules with --error flag.

The primary developer authored a 153-control STRIDE-per-element threat model, implemented content-addressed SHA-256 hashing, Sigstore keyless signing, NUL-byte delimited parsing to prevent field injection, heredoc output injection prevention, ref validation against argument injection, markdown sanitization, and 52 property-based fuzz tests covering all security-critical functions. https://github.com/invariant-systems-ai/aiir/blob/main/THREAT_MODEL.md

THREAT_MODEL.md documents specific countermeasures for: injection (output, argument, markdown, path traversal), spoofing (content addressing, Sigstore), tampering (SHA-256 content hashing + Rekor transparency log), information disclosure (credential stripping, error sanitization), denial of service (JSON depth limits, streaming hashing, max-count), and elevation of privilege (minimal permissions, python -P). 153 controls enumerate specific mitigations.

Uses only SHA-256 (FIPS 180-4, NIST) for content hashing and Sigstore (ECDSA P-256, RFC 6979) for optional signing. All algorithms are publicly published, standardized, and expert-reviewed. No custom or proprietary cryptographic algorithms.

AIIR's primary purpose is receipt generation, not cryptography. It uses Python's standard library hashlib.sha256() for hashing and the sigstore Python library (maintained by the Sigstore project) for signing. No custom cryptographic implementations exist in the codebase.

SHA-256 is provided by Python's stdlib hashlib (PSF License). Sigstore signing uses the sigstore Python library (Apache-2.0). All cryptographic functionality is implemented exclusively with FLOSS components.

SHA-256 provides 256-bit security (exceeds NIST 2030 minimum of 112 bits). Sigstore uses ECDSA P-256 (128-bit security level, exceeds NIST 2030 minimum). No configurable key lengths — only secure defaults are used. No option to downgrade to shorter key lengths.

No broken algorithms are used. The project uses only SHA-256 and ECDSA P-256 — neither is broken or deprecated. No use of MD4, MD5, single DES, RC4, or Dual_EC_DRBG anywhere in the codebase.

No broken algorithms are used. The project uses only SHA-256 and ECDSA P-256 — neither is broken or deprecated. No use of MD4, MD5, single DES, RC4, or Dual_EC_DRBG anywhere in the codebase.

N/A. AIIR does not implement key agreement protocols. It is a CLI tool that produces content-addressed receipts. Sigstore signing uses ephemeral OIDC-based keyless signing — each signature uses a fresh short-lived certificate, providing forward secrecy by design.

N/A. AIIR does not store passwords. It is a CLI tool for receipt generation and verification with no user authentication system.

N/A. AIIR does not generate cryptographic keys or nonces. SHA-256 hashing is deterministic (content-addressed). Sigstore signing delegates all key generation to the sigstore library, which uses Python's secrets module (cryptographically secure) internally.

Delivered via PyPI over HTTPS and GitHub Releases over HTTPS. Installation via "pip install aiir" uses HTTPS by default. GitHub Action is pinned to full SHA commit hashes (not mutable tags). PEP 740 digital attestations provide additional artifact verification.

No cryptographic hashes are distributed over HTTP. All distribution channels use HTTPS. PyPI publishes PEP 740 digital attestations (SLSA provenance + PyPI Publish predicates) cryptographically signed via OIDC, verifiable via PyPI's Integrity API.

No known vulnerabilities exist. Zero CVEs have been assigned against the project. The project is actively maintained and SECURITY.md commits to fixing Critical/High vulnerabilities within 7 days and Medium within 30 days.

No critical vulnerabilities have been reported. SECURITY.md commits to fixing Critical/High within 7 days. The codebase has zero runtime dependencies, minimizing vulnerability surface. Weekly CI schedules (security.yml, codeql.yml) catch new CVEs proactively.

Gitleaks runs on every push and PR scanning full git history for leaked secrets. Semgrep runs p/secrets rules. CI fails if any credential is detected. Three repository secrets are documented in SECURITY.md with 90-day rotation cadence. No credentials exist in source code.

Six static analysis tools run on every PR and block merge: mypy (strict mode, zero errors), ruff (linter + formatter), bandit (security), semgrep (custom + default rules), CodeQL (security-and-quality query suite), and pip-audit (dependency vulnerabilities). All are enforced in CI via security.yml, quality.yml, and codeql.yml. The security-ok and quality-ok gates must pass before merge

Bandit scans for common Python vulnerabilities (hardcoded passwords, insecure hashing, exec/eval, SQL injection patterns). Semgrep applies both default and security-focused rulesets. CodeQL runs GitHub's security-and-quality query suite, which covers injection, authentication, crypto misuse, and OWASP Top 10 categories. All three tools specifically target common vulnerability patterns.

Static analysis findings at medium severity or above block the PR merge via required CI gates (security-ok, quality-ok). They must be resolved before code can land on main. SECURITY.md commits to 7-day fix timelines for Critical/High vulnerabilities. No open static analysis findings exist.

All six static analysis tools (mypy, ruff, bandit, semgrep, CodeQL, pip-audit) run on every push and every pull request via GitHub Actions. CodeQL additionally runs on a weekly cron schedule. Analysis occurs on every commit, exceeding the "at least daily" suggestion.

Hypothesis-based property/fuzz testing (52 fuzz tests generating ~53,000 inputs per run) exercises the software dynamically on every CI run. Mutation testing via mutmut verifies that the test suite detects injected faults. Both are applied before every release as part of the required ci-ok gate.

AIIR is written entirely in Python, a memory-safe language. No C, C++, or other memory-unsafe code is included. Not applicable.

Pytest runs with Python assertions enabled (the default). Hypothesis fuzz tests include explicit property assertions that verify invariants (e.g., receipt round-trip integrity, schema compliance, hash determinism). The CI configuration does not suppress assertions; they are active during all test and fuzz runs.

Dynamic analysis (fuzz testing, mutation testing) is part of the required ci-ok gate. Any medium or higher severity issue discovered blocks the PR merge and must be fixed before code lands on main. SECURITY.md commits to 7-day fix for Critical/High. No open dynamic analysis findings exist.