Does SecOpsium store source code after scanning?
SecOpsium is designed not to retain full repository source code as a product artifact after scanning. It stores findings and metadata needed for remediation and reporting.
Docs
Code Retention
SecOpsium is built to keep scan results useful without turning the SaaS into a permanent store of customer source code.
What SecOpsium stores
SecOpsium stores the data needed to show scan results, remediation state, reports, and history. The goal is to preserve the security workflow, not to preserve a complete copy of the repository.
Stored result data can include findings, severity, rule identifiers, file paths, evidence snippets, remediation guidance, project metadata, workspace metadata, scan timestamps, status, and report context.
This data can still be sensitive because it may reveal repository structure, issue locations, or the presence of secret-like values. It should be treated as security data even when full source code is not retained.
- Findings and severity support prioritization.
- File paths and snippets support remediation.
- Project metadata and scan timestamps support history.
- Report context supports stakeholder communication.
What SecOpsium avoids retaining
SecOpsium is designed not to retain full repository source code as a product artifact after scanning. The scan may process repository content while running, but the dashboard should not become a permanent source-code archive.
The product should store enough finding context for remediation, without keeping a complete copy of the repository in the dashboard. This is the distinction that matters for security reviewers: operational evidence remains, full code retention does not.
- No full source-code archive as a product artifact.
- No GitHub personal access tokens stored for normal GitHub-backed scans.
- No claim that findings are a complete substitute for secure engineering review.
- No report should imply that SecOpsium has retained or manually reviewed all repository files.
Scan-time processing
During a hosted scan, repository content may be cloned or processed in an isolated working area so supported checks can run. That processing is temporary and tied to the scan lifecycle.
Once the scan completes or fails, the temporary working copy should be removed. The dashboard keeps normalized result data, not the repository clone. This gives teams useful findings without turning SecOpsium into another place where their source code permanently lives.
- Repository content can be present during scan execution.
- Temporary scan workspaces should be cleaned up after completion, timeout, or failure.
- Persisted data should be limited to results and remediation context.
- Teams should still avoid committing secrets because any scanner must inspect evidence to find them.
Why snippets exist
Short evidence snippets help teams understand where and why a finding was raised.
The goal is to preserve remediation context while minimizing unnecessary retention of code content. A snippet should be just enough to explain the finding, not a broad reproduction of surrounding source files.
Snippets also make reports more useful. Without any evidence context, teams waste time re-discovering why a finding exists. With too much context, the report can expose more code than needed. SecOpsium should stay on the useful middle ground.
- A snippet should help locate and understand the issue.
- A snippet may include sensitive values and should be protected.
- A snippet is not intended to preserve full source context.
- Teams should rotate or revoke exposed credentials instead of only deleting the snippet.
What users control
Users control which repositories are authorized, when scans are run, and whether GitHub access remains connected. Those controls matter because authorization scope determines what SecOpsium can process.
Teams should periodically review connected repositories, workspace membership, and report sharing practices. A security tool reduces risk only when its own access model stays deliberate.
- Connect only repositories that need assessment.
- Revoke GitHub access when the workflow is no longer needed.
- Limit report access to people who should see security findings.
- Rescan after remediation to confirm supported findings changed.
Retention limits and expectations
Code retention language should be read carefully. It means SecOpsium is designed not to retain full repository source code as a product artifact after scanning. It does not mean the system stores no data at all.
The stored data exists so users can review findings, track remediation, compare scan history, and produce reports. If a customer security reviewer asks what is retained, the accurate answer is findings and metadata, not full repository source code.
Frequently Asked Questions
Why does SecOpsium store file paths or snippets?
File paths and short evidence snippets help users locate and understand findings without requiring full source-code retention in the product.
Is scan metadata still sensitive?
Yes. Findings, paths, snippets, and project metadata can be sensitive and should be protected as security data.
Does no code retention mean no data is stored?
No. SecOpsium stores findings and metadata needed for remediation, reporting, and scan history. It is designed not to retain full repository source code as a product artifact after scanning.
Why does temporary scan processing matter?
A scanner may need to process repository content while checks run. The important retention boundary is that the temporary working copy is removed and the product keeps result context rather than a full source archive.