Scanning Model

A scan starts when a user selects a repository or supported target they are authorized to assess. In the hosted workflow, repository access is requested through the connected authorization path instead of asking the user to paste long lived credentials into the product.

The scan runs in an isolated working area, checks supported repository content and configuration signals, then normalizes matching evidence into findings. After the scan work is complete, the repository clone is removed and the dashboard keeps the scan result data needed for review.

The SaaS stores resulting findings and metadata so the team can review progress, generate reports, and maintain a security cadence. That stored result is intentionally different from keeping a full copy of the repository.

A practical scan lifecycle has several states: repository selection, authorization check, scan preparation, rule execution, result normalization, report update, and cleanup. If a scan fails before completion, the useful state is still explicit: the team should know that a scan failed instead of treating missing results as proof that no findings exist.

Failure states can happen for ordinary reasons such as revoked GitHub access, unavailable repositories, network errors, unsupported target structure, timeout, or scanner execution failure. These states should be handled as operational signals rather than hidden behind an empty result.

A finding is a supported security signal backed by available evidence. It may be a hardcoded secret-like value, a repository posture issue, a client-side exposure signal, or another supported check result.

A finding typically includes a category, severity, rule identifier, file path or target reference where available, short evidence context, and remediation guidance. That context is meant to help the team locate and understand the issue without retaining full source code as a product artifact.

Findings are meant to guide remediation. They are not a claim that SecOpsium has fully audited the system or proven the absence of other issues.

The output of a scan is designed for action, not just storage. Findings feed the project grade, fix queue, security report, and scan history. This gives both technical and non-technical stakeholders a stable way to discuss what changed.

The same finding can appear in several contexts. Engineers may need file paths and remediation guidance, while founders or customers may need a summarized report that explains severity, scope, progress, and limitations.

The open-source SecOpsium CLI provides a way to run and inspect local repository checks.

The SaaS adds hosted execution, team workflows, dashboards, reports, scan history, and prioritization around the findings. The CLI is useful for transparency and local checks; the SaaS is useful when a team needs recurring visibility, shared status, and reportable progress.

A SecOpsium scan does not prove that a repository is free of vulnerabilities, secrets, business logic flaws, dependency issues, or infrastructure risk. It shows the result of supported checks against the available target and context at a point in time.

Teams should combine SecOpsium with secure development practices, code review, provider-side controls, dependency management, incident response planning, and formal assessments when the business requires them.