https://github.com/oscal-compass/compliance-trestle/blob/develop/CONTRIBUTING.md#code-style-and-formating

The project uses the Developer Certificate of Origin (DCO) 1.1 — the same mechanism used by the Linux Kernel community (https://developercertificate.org). This is documented in CONTRIBUTING.md (https://github.com/oscal-compass/compliance-trestle/blob/develop/CONTRIBUTING.md), which explains what Signed-off-by means for this project, provides an example trailer (Signed-off-by: John Doe john.doe@example.com), and instructs contributors to use git commit --signoff. DCO sign-off is technically enforced on every pull request by a dedicated CI workflow (https://github.com/oscal-compass/compliance-trestle/blob/develop/.github/workflows/verify-signoff.yml) that checks every non-merge commit to confirm the Signed-off-by trailer is present and matches the commit author's email address, blocking the PR if it does not.

URL (primary):
https://github.com/oscal-compass/community/blob/main/GOVERNANCE.md

URL (secondary — roles):
https://github.com/oscal-compass/community/blob/main/MEMBERSHIP.md

Justification text:

The compliance-trestle project is governed under the OSCAL Compass community governance model, documented at https://github.com/oscal-compass/community/blob/main/GOVERNANCE.md. This document defines all key roles (Member, Reviewer, Maintainer, Oversight Committee), the two-tier decision-making process (lazy consensus for day-to-day decisions; explicit simple or supermajority voting via GitVote for formal decisions), dispute resolution (escalation to the Oversight Committee with binding authority), and the process for electing and removing leadership. Detailed role requirements and responsibilities are in https://github.com/oscal-compass/community/blob/main/MEMBERSHIP.md. Active project maintainers are listed in the project-level MAINTAINERS.md.

URL:
https://github.com/oscal-compass/community/blob/main/CODE_OF_CONDUCT.md

Justification text:

The project adopts the CNCF Code of Conduct, hosted at the OSCAL Compass community level at https://github.com/oscal-compass/community/blob/main/CODE_OF_CONDUCT.md. It is referenced from the project README.md ("Participation in the OSCAL Compass community is governed by the Code of Conduct") and from the project's documentation site at https://oscal-compass.github.io/compliance-trestle/latest/contributing/code_of_conduct/.

URL (primary — role definitions):
https://github.com/oscal-compass/community/blob/main/MEMBERSHIP.md

Justification text:

Key roles and their responsibilities are defined in https://github.com/oscal-compass/community/blob/main/MEMBERSHIP.md, which documents the Member, Reviewer, Maintainer, and Oversight Committee roles — including requirements to hold each role, specific responsibilities, and privileges. Who holds each role is publicly named in two places: project-level maintainers (Maintainer role) are listed with their GitHub handles in https://github.com/oscal-compass/compliance-trestle/blob/develop/MAINTAINERS.md, and org-level role holders (Oversight Committee, Org Admins, Community Maintainers) are listed with their GitHub handles and affiliations in https://github.com/oscal-compass/community/blob/main/MAINTAINERS.md.

Access Continuity Explanation for OpenSSF Best Practices [access_continuity]

The project satisfies the access continuity requirement through shared organization administration, distributed maintainership, and documented governance procedures:

1. Multi-Admin and Multi-Org Redundancy: Administrative access, credentials, and repository rights across the oscal-compass organization are shared among multiple Org Admins from different member organizations, plus a Linux Foundation backstop account (thelinuxfoundation). This ensures that operations (managing issues, merging pull requests, releasing software) can proceed without disruption if any single person is lost.
2. Succession and Vacancy Rules: Formal vacancy appointment and governance policies allow the multi-member Oversight Committee to reallocate responsibilities and maintain uninterrupted project continuity within one week.

Reference URLs

• https://github.com/oscal-compass/community/blob/main/GOVERNANCE.md#access-continuity
• https://github.com/oscal-compass/community/blob/main/MAINTAINERS.md#org-admins
• https://github.com/oscal-compass/community/blob/main/GOVERNANCE.md#vacancies

OpenSSF Silver — bus_factor Justification
Project: OSCAL Compass · Criterion ID: bus_factor

Criterion
The project SHOULD have a bus factor of 2 or more.
URL
https://github.com/oscal-compass/community/blob/main/GOVERNANCE.md#access-continuity
Justification
OSCAL Compass maintains a bus factor of 2 or more. The project's Access Continuity governance section documents that no single person is a point of failure. A six-member Oversight Committee drawn from at least three independent organizations (IBM, Red Hat, Sunstone Secure) collectively holds all necessary repository access, credentials, and legal rights. Multiple Org Admins — including a Linux Foundation backstop — ensure continuity of operations. Project knowledge is actively distributed across contributors from different organizations, so the project can continue to function within one week of losing any individual contributor. Vacancies are filled by appointment per the documented Vacancies process.

ROADMAP.md is a dedicated, top-level file that explicitly describes what the OSCAL Compass project intends to do (5 named goals covering codebase maintenance, agentic authoring, community growth, OpenSSF Best Practices, and CNCF Incubation) and not do (enterprise support, certification authority functions, vulnerability scanning, and legacy format support) over the next year.

Key URL:

https://github.com/oscal-compass/community/blob/main/ROADMAP.md
The document is intentionally high-level (not feature-by-feature), which is exactly what the criterion expects — enough for potential users and contributors to understand the project's direction without requiring exhaustive detail.

documentation_architecture — Compliance Evidence
Project: compliance-trestle (oscal-compass) · Criterion: The project MUST include documentation of the architecture (high-level design) of the software it produces.

Requirement Summary
A software architecture explains a program's fundamental structures — its major components, the relationships among them, and the key properties of those components and relationships. The criterion requires at least one URL pointing to that documentation.

Primary URL (Published Documentation)
Live architecture page
https://oscal-compass.github.io/compliance-trestle/latest/architecture/
This is the publicly hosted, versioned architecture page rendered from the project's MkDocs-Material documentation site. It is permanently accessible under the latest alias managed by mike.

Secondary URL (Repository Source)
Markdown source in repository (develop branch)
https://github.com/oscal-compass/compliance-trestle/blob/develop/docs/architecture.md
The architecture document is tracked under version control alongside the code it describes at docs/architecture.md.

What the Architecture Document Covers
The document addresses all three elements the criterion requires.

1. Major Components
   Eight distinct architectural layers are identified and mapped to their source locations:

Layer Location in codebase
Plugin Extension Point trestle/core/plugins.py
Entry Points — CLI & Python API trestle/cli.py, trestle/core/repository.py
Command Layer trestle/core/commands/
Catalog API trestle/core/catalog/
Profile Resolver trestle/core/profile_resolver.py, trestle/core/resolver/
Validator Framework trestle/core/validator.py, trestle/core/validator_factory.py
Markdown / Jinja / DrawIO Authoring trestle/core/control_{reader,writer}.py, trestle/core/markdown/, trestle/core/jinja/, trestle/core/draw_io.py
Signing & Canonicalization trestle/core/signing.py, trestle/core/canonicalization.py
Transform & Task Pipeline trestle/transforms/, trestle/tasks/
OSCAL Object Model trestle/oscal/, trestle/core/base_model.py
Workspace & Remote I/O trestle/common/, trestle/core/remote/cache.py
2. Relationships Among Components
A full ASCII component map in the document diagrams how the layers connect, with named, annotated edges:

Plugin packages inject CommandBase subclasses into Trestle.subcommands at module import time.
The CLI and Python API both dispatch to the Command Layer.
Commands delegate business logic to Core Services (Catalog API, Profile Resolver, Validators, Authoring, Signing).
All Core Services read and write through the OSCAL Object Model.
The OSCAL Object Model serialises to/from Workspace & Remote I/O.
3. Key Properties of Components and Relationships
Five named design properties are documented:

Property Description
Workspace-centric storage A .trestle/-rooted directory tree; documents may be single files or split into sub-directory hierarchies following the object hierarchy.
Schema-enforced I/O Every disk read/write passes through the Pydantic v2 model layer, guaranteeing schema validity at the boundary between disk and memory.
Composable pipelines Pipeline / Filter pattern (trestle/core/pipeline.py) used for profile resolution and OSCAL assembly; stages are independently testable and reusable.
Separation of concerns: CLI vs. API Commands delegate to core service classes; repository.py exposes the same services to Python callers without going through the CLI argument layer.
Extensibility via plugins The trestle_* package naming convention allows third-party command packages to be auto-discovered without any core dependency on them.
The document also includes a Security Requirements & Guarantees section specifying what users can and cannot rely on: input validation, SSRF protection, Jinja sandboxing, cryptographic provenance (DSSE / in-toto), supply chain integrity (SLSA), plugin trust boundaries, and encryption-at-rest limitations.

Integration with Broader Documentation Site
The architecture page is a top-level navigation item in the project's documentation site at https://oscal-compass.github.io/compliance-trestle/latest/, which is referenced from the project README.md:

"Complete documentation, tutorials, and background on compliance can be found here."
Criterion Satisfaction Summary
Criterion element Status Evidence
URL to architecture documentation ✅ Met oscal-compass.github.io/…/architecture/
Source file in repository ✅ Met docs/architecture.md (develop branch)
Major components identified ✅ Met 11 layers named and mapped to source paths
Relationships among components ✅ Met ASCII component map with labeled directional edges
Key properties of components/relationships ✅ Met 5 named design properties + security guarantees section
Versioned & publicly accessible ✅ Met MkDocs-Material + mike, always available at /latest/architecture/

documentation_security — Compliance Evidence
Project: compliance-trestle (oscal-compass) · Criterion: The project MUST document what the user can and cannot expect in terms of security from the software produced by the project (its "security requirements"). (URL required)

Requirement Summary
The project must publish documentation that explicitly states the security properties the software is designed to provide (guarantees) and the security properties it explicitly does not provide (boundaries and user responsibilities). At least one URL is required.

URL 1 — Architecture: Security Requirements & Guarantees Section
Published documentation page (direct anchor)
https://oscal-compass.github.io/compliance-trestle/latest/architecture/#security-requirements-guarantees
Markdown source in repository (develop branch)
https://github.com/oscal-compass/compliance-trestle/blob/develop/docs/architecture.md#security-requirements--guarantees
The architecture document contains a dedicated Security Requirements & Guarantees section that directly addresses what users CAN and CANNOT expect. It is structured in exactly the two-part form the criterion requires:

What Users CAN Expect (Security Guarantees & Capabilities)
Input Validation & Schema Enforcement — All OSCAL models are parsed and validated via strict Pydantic v2 models derived from official NIST OSCAL schemas. Malformed documents, invalid types, or unexpected structures are rejected at parse time.
SSRF & Remote Resource Protection — Remote resource retrieval (trestle/core/remote/cache.py and trestle/core/remote/security.py) enforces HTTPS/SFTP and includes SSRF protections. Cloud metadata endpoints (e.g., 169.254.169.254, metadata.google.internal) and loopback addresses are blocked unconditionally. RFC 1918 private IP blocking is configurable via TRESTLE_BLOCK_PRIVATE_IPS.
Template Sandbox Execution — Jinja2 authoring templates execute within a SandboxedEnvironment, restricting access to dangerous Python attributes and mitigating server-side template injection (SSTI) risks.
Cryptographic Provenance & Integrity — Built-in sign / verify / sign-manifest / verify-manifest commands use RFC 8785 JSON canonicalization and in-toto / DSSE signatures via securesystemslib to establish tamper-evident document provenance.
Supply Chain Integrity — Release distributions include SLSA build provenance attestations and PyPI trusted publishing.
What Users CANNOT Expect (Security Boundaries & User Responsibilities)
No Execution Isolation for Third-Party Plugins — Trestle discovers and loads trestle_* plugins from sys.path without sandboxing. Users are responsible for ensuring installed plugins are trusted.
No Protection Against Malicious Local Files / Filesystem Attacks — Trestle runs with the permissions of the invoking user and assumes the host filesystem is secure.
No Automatic Encryption at Rest — Trestle does not encrypt stored OSCAL models or workspace files; encryption must be provided by the OS or filesystem.
No Verification of Semantic Content Accuracy — Schema and cross-reference integrity are validated; the accuracy, adequacy, or legal validity of compliance content within documents is not.
No Network-Level Access Controls — Beyond URL validation during remote fetches, Trestle does not manage network transport security or proxy configuration.
URL 2 — SECURITY.md (Repository Security Policy)
SECURITY.md in repository
https://github.com/oscal-compass/compliance-trestle/blob/develop/SECURITY.md
SECURITY.md provides deeper technical detail on the security features users can rely on, serving as an additional reference for the "CAN expect" side of the requirement:

Security Feature Detail
SSRF Protection — Tier 1 (always blocked) Loopback (127.0.0.0/8, ::1/128), link-local (169.254.0.0/16, fe80::/10), and cloud metadata endpoints (AWS/Azure/GCP/Alibaba) are blocked unconditionally.
SSRF Protection — Tier 2 (configurable) RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) allowed by default; blocked when TRESTLE_BLOCK_PRIVATE_IPS=true. Private-IP accesses are logged as warnings.
Domain Allowlist Remote fetches can be restricted to a configured set of trusted domains.
Path Traversal Protection URL path validation blocks .. sequences; cache path validation confines files to the cache directory; workspace boundary enforcement; sensitive file protection (SSH keys, cloud credentials, /etc/passwd, /proc/self/environ, etc.).
Scheme Restrictions Only HTTPS and SFTP are permitted for remote URLs. HTTP, FTP, and other schemes are rejected.
Port Restrictions Only standard ports are allowed by default (HTTPS: 443, SFTP: 22). Non-standard ports are blocked unless explicitly configured.
Security Testing Coverage SSRF and path traversal protections carry 100% code coverage. Tests include all Tier 1/Tier 2 addresses, path traversal vectors, sensitive file access attempts, and real-world attack scenarios from security advisories.
Vulnerability Disclosure Delegates to the OSCAL Compass Community Security Policy; includes a published advisory (GHSA-w76h-q7c6-jpjp) documenting a past SSRF fix.
Criterion Satisfaction Summary
Criterion element Status Evidence
URL to security requirements documentation ✅ Met (2 URLs) Architecture page § Security Requirements & Guarantees; SECURITY.md
What users CAN expect (security guarantees) ✅ Met Input validation, SSRF protection, Jinja sandbox, cryptographic provenance, supply chain integrity — documented with implementation details and source paths
What users CANNOT expect (security boundaries) ✅ Met Plugin isolation, filesystem security, encryption at rest, semantic accuracy, network controls — each explicitly called out as out-of-scope
Technical depth of security feature documentation ✅ Met SECURITY.md details two-tier SSRF system, path traversal protections, scheme/port restrictions, and test coverage
Versioned & publicly accessible ✅ Met Architecture page published at /latest/architecture/; SECURITY.md in develop branch on GitHub

REQUIREMENT: documentation_quick_start

The project MUST provide a "quick start" guide for new users
to help them quickly do something with the software. (URL required)

HOW IT IS MET

File : docs/quick-start.md
URL : https://oscal-compass.github.io/compliance-trestle/latest/quick-start/

The guide walks a new user through five steps in under five minutes:

1. Install: pip install compliance-trestle
2. Init: trestle init
3. Import: trestle import -f <NIST SP 800-53 Rev5 Moderate URL> -o nist-800-53-r5-moderate
4. Validate: trestle validate -f catalogs/nist-800-53-r5-moderate/catalog.json
5. Explore: trestle describe -f catalogs/nist-800-53-r5-moderate/catalog.json

Each step includes expected terminal output.
The guide is also linked from README.md (line 73).

REFERENCES

Source : docs/quick-start.md
URL : https://oscal-compass.github.io/compliance-trestle/latest/quick-start/

This community repository (the OSCAL Compass community repo) uses several complementary mechanisms to keep documentation consistent with the current state of the project:

1. CI/CD documentation quality gates on every PR
   Every pull request targeting main that touches any *.md file is automatically checked by two GitHub Actions workflows:

.github/workflows/docs.yml — runs markdownlint-cli2 across all Markdown files. This enforces structural consistency and catches malformed documentation before it can be merged.
.github/workflows/ci.yml — runs spellcheck (pyspelling + aspell) on every Markdown file. A custom wordlist at .github/wordlist.txt keeps project-specific terminology (tool names, acronyms) from being flagged as errors.
Taken together, no documentation change can be merged without passing both lint and spell checks, preventing degraded or careless updates from landing.

2. OSCAL proposal validation keeps structured docs in sync
   .github/workflows/proposals.yml installs Trestle (the project's own tool) from requirements.txt and runs trestle author docs validate against the proposals/ directory on every PR. This means the project eats its own dog food — the same OSCAL compliance tooling the project produces is used to validate the project's own structured documentation artifacts.

3. README and CONTRIBUTING reflect current project structure
   README.md and CONTRIBUTING.md both list the current four repositories (Trestle, Agentic Agile Authoring, Agile Authoring, C2P) with up-to-date descriptions, including the recently added Agentic Agile Authoring project. This shows that documentation is actively kept in sync as new sub-projects are added to the community.

4. PR-based change process mandates documentation updates
   CONTRIBUTING.md explicitly calls out documentation as a valid and valued contribution:

"documentation can always use improvement … If you see something that you think should be fixed, take ownership!"

All changes — including documentation fixes — go through pull requests, meaning every change is reviewable, trackable, and auditable. Known inconsistencies can be opened as issues and fixed via the standard PR workflow.

5. Living governance and membership documents
   GOVERNANCE.md, MAINTAINERS.md, MEMBERSHIP.md, and EMERITUS.md are updated through the same PR process whenever the community structure changes (e.g., a maintainer steps down triggers both a MAINTAINERS.md PR and an EMERITUS.md update). This keeps human-readable governance documentation consistent with the actual state of the project.

Key URLs
Resource Purpose
https://github.com/oscal-compass/community/blob/main/README.md Primary community documentation, kept current
https://github.com/oscal-compass/community/actions/workflows/docs.yml CI lint gate on all Markdown PRs
https://github.com/oscal-compass/community/actions/workflows/ci.yml CI spellcheck gate on all Markdown PRs
https://github.com/oscal-compass/community/actions/workflows/proposals.yml Trestle-based validation of structured proposal docs
https://github.com/oscal-compass/community/blob/main/CONTRIBUTING.md Contributing guide that treats doc fixes as first-class contributions
In summary: The criterion is met through automated CI gates that block inconsistent documentation from merging, a PR-based change process that tracks and reviews every documentation update, the project's own tooling used to validate its structured docs, and actively maintained community documents (README, CONTRIBUTING, GOVERNANCE, MAINTAINERS) that reflect the current state of all sub-projects and governance structures.

documentation_achievements — Criterion Met
Project: compliance-trestle (oscal-compass) | OpenSSF Best Practices

Criterion: The project repository front page and/or website MUST identify and hyperlink to any achievements, including this best practices badge, within 48 hours of public recognition that the achievement has been attained.

✓ MET
How It Is Met
The GitHub repository front page is the project's README.md. Lines 10–11 of that file display two OpenSSF achievement badges at the very top of the page, each hyperlinked to its public recognition/results page. Any visitor to github.com/oscal-compass/compliance-trestle sees these badges immediately without scrolling.

Achievement Badges in README.md (lines 10–11)
Line 10:
Line 11:
Key URLs
Achievement Badge / Recognition URL Location in Repo
OpenSSF Best Practices https://www.bestpractices.dev/projects/9408 README.md, line 10
OpenSSF Scorecard https://scorecard.dev/viewer/?uri=github.com/oscal-compass/compliance-trestle README.md, line 11
Repository front page https://github.com/oscal-compass/compliance-trestle GitHub (renders README.md)
Both badges are placed at the top of README.md — the de-facto front page for any GitHub-hosted project — satisfying the requirement that achievements are identified and hyperlinked on the project repository front page within 48 hours of public recognition.

Accessibility — compliance-trestle
How the project meets WCAG 2.0 accessibility best practices

Project type
Compliance-trestle is primarily a command-line application and Python library. CLI tools are inherently accessible: they emit plain text to stdout/stderr, work in any terminal (including Braille displays), support --help on all sub-commands, and do not use colour as the sole means of conveying information. The project also publishes a documentation website (MkDocs Material) where the WCAG criteria below apply.

WCAG 2.0 criteria
Criterion Requirement How it is met
1.1.1 Text alternatives All images in the documentation carry descriptive alt text that conveys the same information as the visual. Decorative images are labelled as such.
1.4.1 Use of colour Colour is never the only means of conveying information. Code blocks use contextual labels and prose alongside colour highlighting. CLI messages carry a textual prefix (INFO / WARNING / ERROR).
1.4.3 Contrast ≥ 4.5:1 The documentation site offers a light/dark theme toggle that respects the user's prefers-color-scheme OS setting. Inline code colours in both palettes meet the 4.5:1 minimum.
2.1.1 Keyboard accessible The documentation site navigation is fully keyboard-accessible. A "Skip to main content" link is the first focusable element on every page so keyboard-only users can bypass the navigation bar.
2.4.1 Bypass blocks The skip-navigation link targets the main content container so the first Tab keypress delivers focus directly to page content.
2.4.7 Focus visible A high-contrast focus ring is applied to all interactive elements, restoring the outline the theme resets by default.
3.1.1 Language of page Every page is served with <html lang="en"> so screen-readers announce the correct language.
Additional: reduced motion
CSS animations and transitions are disabled when the user's OS "reduce motion" preference is active, per prefers-reduced-motion (WCAG 2.3.3).

Screen-reader testing
Basic compatibility verified with Orca (GNOME, Linux). The skip-navigation link and ARIA landmark structure allow Orca users to reach the main content without traversing the full sidebar.

References
WCAG 2.0 specification
Understanding WCAG 2.0
W3C Web Accessibility Initiative (WAI)

Internationalization — compliance-trestle
How the project meets the i18n best-practices requirement — see W3C: Localization vs. Internationalization

✓ Requirement met — partially N/A, partially addressed
What text the project produces
Output type Audience i18n applies?
OSCAL JSON / YAML artifacts Machine-to-machine interchange; content is authored by the user, not generated by trestle N/A — structured data, not trestle-generated natural language
CLI log messages & --help text Developers and compliance engineers running the tool Applies — English hardcoded today; no gettext wrapping
Markdown governance output Content is templated and authored by the user; trestle supplies structural scaffolding only N/A — trestle does not generate localizable natural-language prose
Documentation website English-speaking developers N/A for the requirement — static documentation, not software output
How the requirement is met
The dominant output of compliance-trestle is machine-readable OSCAL data (JSON/YAML). This data is structured entirely by the user's own content; trestle acts as a schema-enforcing pipeline and does not inject localizable natural-language text into it. For this majority of the software's output, the i18n criterion is not applicable.

The CLI does produce a smaller volume of human-readable text — log messages and --help strings — that is currently English-only. The codebase is already prepared for i18n in the following structural ways:

Every source file declares # -- coding:utf-8 --, ensuring all string literals are UTF-8 and can contain any Unicode character without modification.
All user-facing strings are plain Python string literals, making them straightforward to wrap with Python's standard gettext module when a translation catalogue is needed — no architectural changes are required.
No locale-sensitive operations (date formatting, number formatting, sorting of human-readable text) are performed on data that trestle itself generates; where timestamps appear in OSCAL output they follow the ISO 8601 standard, which is locale-neutral.
The documentation site sets lang="en" explicitly, so the language of all human-readable site content is declared and unambiguous to translation tools.
Summary
The bulk of trestle's output (OSCAL artifacts, markdown scaffolding) is N/A for i18n because it carries user-authored content, not software-generated natural language. The small portion that does generate end-user text (CLI messages) is structurally ready for gettext-based localization: UTF-8 source encoding is declared throughout, strings are plain literals with no locale-sensitive formatting, and no architectural changes would be needed to add a translation catalogue.

References
W3C: Localization vs. Internationalization
Python gettext — Internationalization Services
W3C: Declaring language in HTML

The project uses GitHub for repository hosting and access management, and GitHub Pages for its documentation site. Neither the project itself nor any of its sites store passwords for authenticating external users — all inbound authentication is delegated entirely to GitHub and PyPI, both of which use industry-standard iterated-hash password storage. The use of GitHub directly satisfies this criterion. N/A.