Design a community connector contract for SSDLC artifacts

[arthurpanhku]

Why this matters

DocSentinel becomes more valuable when it can sit naturally inside existing SSDLC workflows. Every team has different tools: GitHub/GitLab, Jira, CI scanners, SBOM generators, SAST/DAST platforms, ticketing systems, and evidence repositories.

From first principles: open-source projects scale integrations best when the core defines a stable adapter contract and the community can add connectors without touching core assessment logic.

Community help wanted

We need a public connector contract and starter adapters for common SSDLC artifacts.

Suggested scope

• Define a minimal adapter interface for importing artifacts and exporting assessment results.
• Add sample adapters for GitHub issues/PR context, SARIF, CycloneDX SBOM, and generic JSON evidence.
• Document how connectors should handle secrets, rate limits, retries, and provenance metadata.
• Add contract tests so community connectors remain compatible.
• Keep provider-specific integrations optional and disabled by default.

Acceptance criteria

• A connector interface and documentation exist.
• At least one sample adapter is implemented with tests.
• Contract tests can validate third-party adapters.
• The design keeps secrets out of logs, reports, and committed fixtures.

[arthurpanhku]

Roadmap update: concrete community connector slices

The connector contract should align with Evidence Envelope v1 (#43). Community-ready implementations are now split into:

• [P0][Community] Add SARIF 2.1.0 ingestion and normalized finding validation #44 SARIF ingestion;
• [P0][Community] Add CycloneDX and SPDX SBOM ingestion with quality checks #45 CycloneDX/SPDX SBOM ingestion;
• [P1][Community] Validate OSCAL exports against official schemas and add round-trip fixtures #47 OSCAL conformance;
• [P1][Community] Ship a docsentinel gate CLI and reusable GitHub Action #48 docsentinel gate CLI and GitHub Action.

After the contract stabilizes, additional contributors are invited to propose GitLab, Azure DevOps, Jenkins, Jira, and ServiceNow adapters. Provider-specific credentials must remain optional, narrowly scoped, redacted, and outside core assessment logic.