This page collects the practical answers teams usually need before connecting a repository, deciding what to fix, running a later validation, or sharing a report.
It means checking supported product-security conditions on a repeatable cadence, prioritizing the resulting evidence, acting on the most important risks, and running another validation to see what changed. In SecOpsium, that cadence can be manual or scheduled; it is not a claim of real-time monitoring.
A scanner produces signals. Validation turns supported signals into an operating loop with explicit scope, evidence-aware priority, remediation guidance, a later check, history, and reports that show what remains unresolved.
No. SecOpsium helps a lean team maintain a practical product-security workflow before it has dedicated AppSec staff. It does not replace expert architecture review, incident response, penetration testing, compliance work, or human security judgment.
Current coverage includes supported secrets and code findings in repositories, client-side and web exposure signals, GitHub repository configuration checks, GitHub and GitLab repository workflows, evidence-aware prioritization, A–F grades, fix queues, scan history, and reports.
SecOpsium does not currently claim full software-composition analysis, infrastructure-as-code scanning, container or cloud posture scanning, live credential validity checks, complete attack-path discovery, or guaranteed detection of every vulnerability.
No. Repository configuration validation currently covers specific GitHub controls such as branch protection, required reviews, repository visibility, SECURITY.md, secret-scanning availability, Dependabot availability, and stale default branches where the provider API returns enough evidence.
Severity describes the technical seriousness of a finding. Exposure describes how reachable or public the evidence appears. Impact describes what supported evidence suggests could be affected. Priority is the practical fix order produced from those signals and remains open to stronger business context.
No. SecOpsium uses evidence-backed impact analysis to label context as known, partial, conditional, or unknown. It does not invent missing dependencies or claim a complete attack path.
The grade summarizes the current result of supported validation coverage. It helps teams see direction and unresolved risk; it is not proof that the product is completely secure.
No. SecOpsium provides a prioritized fix queue and guidance such as rotate, revoke, remove, restrict, harden, or review. Your team applies the change and controls the release.
After your team changes the product or repository, a new scan evaluates the same supported conditions. Comparing the new result with prior scan history shows whether the finding is absent from the later validation; it does not prove the issue was removed from every external system.
Supported plans can schedule scans. Teams can also run validations manually before a release or after a fix. Scheduled checks are periodic, not real-time monitoring.
Yes. An authorized GitLab OAuth connection can list and scan accessible public or private repositories. Access is limited by the scopes and projects granted to that GitLab identity.
GitHub repository access uses a GitHub App and short-lived installation tokens. GitLab uses OAuth access and refresh credentials stored in Vault so access can be refreshed for authorized manual and scheduled scans. Both connections can be disconnected from SecOpsium.
Not currently. GitLab supports provider-authorized code validation and scheduling. The repository configuration audit is currently implemented against GitHub controls.
SecOpsium processes an authorized repository in a temporary scan workspace and is designed to remove that workspace after the scan attempt. It retains findings, paths, short evidence snippets, scan state, and report history rather than a product copy of the repository.
GitHub App installation tokens are generated for short-lived use. GitLab OAuth access and refresh credentials are stored in Vault, referenced from the application database, and deleted locally when the connection is disconnected; provider-side revocation is attempted and reported.
Yes. GitHub App access can be removed through GitHub or disconnected in SecOpsium. GitLab connections can be disconnected in SecOpsium, which deletes the stored Vault credential and attempts provider-side token revocation.
SecOpsium can provide current technical validation evidence, remediation history, scope, and security-practice documentation that may help a review. It does not certify SOC 2 or ISO 27001 compliance and does not replace an auditor or control program.
No. Reports summarize supported automated validation evidence and its limitations. They do not replace a penetration test, audit, certification, architecture review, or customer approval process.
They can support a careful conversation by showing current scope, findings, fix order, later validations, and known limitations. The receiving customer decides what evidence is sufficient.