Is SecOpsium safe to use with private repos?
Yes. SecOpsium scans repositories through authorized GitHub access, uses short-lived tokens, and does not store your source code after scanning.
This page collects the practical answers teams usually need before connecting a repository, reading a report, or comparing the SaaS workflow with the open-source CLI.
Yes. SecOpsium scans repositories through authorized GitHub access, uses short-lived tokens, and does not store your source code after scanning.
SecOpsium is built for startups and SMEs that need fast security validation without a dedicated security team. It combines secrets, web exposure, configuration checks, severity grading, and a focused fix queue.
A security grade is an A-F summary of scan results weighted by severity and risk. It helps teams see whether their project is improving and what to fix first.
Blast radius shows what systems or workflows could be affected by a finding. SecOpsium maps supported service boundaries and avoids guessing when evidence is incomplete.
Yes. SecOpsium prioritizes findings, explains severity, and turns scan results into a fix queue that product and engineering teams can act on directly.
Secrets detection finds credentials and credential like values, such as API keys, tokens, passwords, and private configuration values, inside repository content.
No. SecOpsium helps detect supported secret patterns and prioritize remediation, but teams should still use secure development practices, key rotation, code review, and provider side controls.
The safest response is to rotate or revoke the exposed credential, remove it from code, review where it was used, and prevent the same pattern from being committed again.
SecOpsium connects through an authorized GitHub workflow so users can select repositories they are allowed to scan. It does not require sharing a personal access token with the product.
SecOpsium is designed to scan repositories the user has authorized, including private repositories where the connected GitHub access permits it.
The CLI gives technical users a transparent way to inspect and run local checks, while the SaaS focuses on hosted workflows, team visibility, recurring scans, reports, and prioritization.
Repository security protects the source code, configuration, permissions, credentials, and release workflow around a software repository.
SecOpsium helps with supported risks such as hardcoded secrets, repository posture signals, and findings that can be translated into a fix queue and security grade.
No. Startups and SMEs also need repository security because a single exposed credential or risky setting can create real operational and customer risk.
The grade is an A-F summary of supported findings and severity. It helps teams understand posture quickly and decide what needs attention first.
No. A good grade means supported scans found fewer or lower risk issues. It is not proof that every security problem has been found.
The fix queue is for founders, engineering leads, and developers who need an ordered list of practical remediation work.
A SecOpsium report summarizes supported findings with severity, evidence context, remediation guidance, grade impact, and progress oriented language.
No. SecOpsium reports help explain supported repository and scanning findings, but they do not replace a full penetration test or formal security audit.
Reports are written for engineers who need details and for founders, CTOs, or stakeholders who need clear risk context.
Client-side exposure detection looks for sensitive or risky values in frontend and web facing contexts where users or automated tools may be able to see them.
No. Some keys are designed to be public and restricted by origin or scope. The risk depends on what the key can access and whether it is properly constrained.
Teams should rotate exposed credentials, move sensitive operations server-side, restrict key permissions, and rescan to confirm the exposure is gone.
SecOpsium checks an authorized repository or target for supported security signals, normalizes the results, and presents findings with severity and remediation guidance.
No. A scan shows what supported checks found at that time. It does not prove that every issue has been found or that the repository is completely secure.
Scan history helps teams compare posture over time, confirm remediation, and avoid treating each security check as a one-off event.
SecOpsium is designed around an authorized GitHub workflow rather than asking users to paste a personal access token into the product.
Yes. Repository visibility depends on the scope authorized through GitHub. Teams should grant access only to repositories they want SecOpsium to assess.
Yes. Users can revoke or disconnect the GitHub authorization when they no longer want SecOpsium to access the selected repositories.
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.
File paths and short evidence snippets help users locate and understand findings without requiring full source-code retention in the product.
Yes. Findings, paths, snippets, and project metadata can be sensitive and should be protected as security data.
Severity scoring ranks findings by expected risk and urgency so teams can decide what to fix first.
Higher-severity findings generally have more impact on the grade because they represent issues that need faster attention.
Yes. Scoring is based on supported evidence and context. Teams should review findings and adjust their response based on what they know about their environment.
A SecOpsium report helps teams communicate supported security findings, severity, remediation guidance, grade context, and progress.
It may be useful as supporting evidence, but teams should avoid presenting it as a full independent audit unless that is actually true.
Clear limitations make the report more trustworthy by explaining what was checked and what the report does not prove.
A detection rule is a supported check that identifies a security signal, such as a secret-like value or repository posture issue.
Yes. Some findings require human review because context determines whether the signal is truly risky.
Yes. Detection coverage has limits, especially for unknown patterns, custom formats, and risks outside supported checks.
Yes. The CLI is available at github.com/secopsium/secopsium-cli so technical users can inspect and run local checks.
No. The CLI is useful for local checks and transparency. The SaaS adds hosted scans, dashboards, reports, scan history, prioritization, and team workflows.
A CLI helps build trust and gives technical teams a practical local option, while the SaaS handles collaboration, reporting, and ongoing security operations.