How SecOpsium handles source access, credentials, and validation evidence.

SecOpsium accesses only the repository, branch, application URL, and provider context needed for the validation a user is authorized to run. GitHub and GitLab expose different authorization models, so their credentials and revocation behavior are described separately below.

• Repository content for supported code validation.
• Public web assets reached by a supported web-exposure validation.
• Supported GitHub repository settings when configuration audit is selected.
• Project, scan, finding, grade, history, and report data needed for the product workflow.

GitHub repository access uses a GitHub App. The installation scope determines which repositories SecOpsium can access, and short-lived installation tokens are requested for authorized work.

GitLab repository access uses OAuth with PKCE. The connected identity and granted OAuth scopes determine which projects and branches can be listed or validated. Access and refresh credentials are stored in Vault so authorized manual and scheduled scans can refresh access; the application database stores a credential reference and non-secret metadata.

• GitHub access can be removed from GitHub or disconnected in SecOpsium.
• Disconnecting GitLab deletes the stored Vault credential and attempts provider-side revocation.
• GitLab provider revocation is best-effort and can be reported as unconfirmed even after local credential deletion.
• GitLab supports code validation; the current repository configuration audit is GitHub-specific.

Repository content is cloned into a temporary scanner workspace for the authorized scan attempt. The scanner workflow is designed to remove that workspace when processing completes or fails.

No software can honestly promise that every infrastructure crash, host interruption, or operating-system failure always reaches application cleanup code. SecOpsium therefore describes source-code non-retention as a product and operational design, not as an impossible absolute about every failure mode.

• Repository content is processed for the selected validation rather than retained as a product copy.
• Temporary processing artifacts are not intended to become report or database records.
• Operational cleanup failures should be investigated as security incidents rather than hidden by policy language.

SecOpsium retains the evidence and state needed to make validations comparable and reports understandable.

• Findings, rule identifiers, categories, severity, remediation guidance, and qualified impact context.
• Repository paths and short sanitized evidence snippets where required for review.
• Project, scan, attempt, schedule, grade, fix-queue, history, and report records.
• Account, workspace, authorization metadata, and provider connection references.
• GitLab OAuth credentials in Vault, not directly in the application database.

The hosted product is not designed to retain a complete copy of a customer's source repository or Git history after the temporary scan workspace is removed.

• A product copy of full source files or repository history.
• GitHub App installation tokens after their short-lived use.
• Raw full scanner artifacts as customer-facing report data.
• AI prompts, IDE sessions, coding-agent memory, or authorship telemetry.

Authorization checks bind projects and scans to personal or workspace ownership context. Internal scan and callback workflows validate project, attempt, event, and tenant identities before accepting state changes.

• Workspace roles constrain who can manage integrations and projects.
• Project-level authorization is checked before user-facing scan operations.
• Durable dispatch claims fence duplicate or stale worker callbacks.
• Isolation controls reduce risk but do not justify claiming that a service can never contain a defect.

Operational logs and durable evidence are designed to favor identifiers, outcomes, timing, and sanitized metadata over repository content or provider credentials.

• Provider tokens and secret values should not be written to structured workflow logs.
• Evidence snippets are intentionally short and should be reviewed as sensitive security metadata.
• Validation history records what the supported workflow observed, including incomplete or unknown context.

The production architecture separates public entry points, application services, scanning workers, queues, the database, and Vault-backed secret delivery. Services use scoped credentials and health checks appropriate to their role.

• Vault is used for production secret delivery and GitLab OAuth credential storage.
• Scanner workers run separately from the public frontend and application API.
• Rate limiting, security headers, container limits, and authenticated internal routes are used where implemented.
• Infrastructure safeguards are layered controls, not a guarantee against every outage or compromise.

If you believe you have found a vulnerability in SecOpsium, contact the address published on this site with enough detail to reproduce and assess the issue. Do not access data or systems beyond what you are authorized to test.

• Include the affected route or component, reproduction steps, and observed impact.
• Avoid sending live customer credentials or unnecessary sensitive data.
• We will acknowledge and triage good-faith reports as operational capacity allows.

SecOpsium does not currently claim SOC 2 certification, ISO 27001 certification, or that its product reports are formal audits or penetration tests. Product-security validation evidence may support a customer's review, but it does not replace an auditor, control program, independent test, or customer approval process.