Does SecOpsium ask for a GitHub personal access token?
SecOpsium is designed around an authorized GitHub workflow rather than asking users to paste a personal access token into the product.
Docs
GitHub Permissions
SecOpsium should only scan repositories the user owns or is explicitly authorized to assess. The GitHub workflow is designed around scoped repository access instead of shared personal tokens.
Authorization model
SecOpsium connects to GitHub through an authorized GitHub workflow. Users choose the repository scope they want SecOpsium to access, and scans should only run against repositories inside that approved scope.
For private repositories, access depends on the permissions granted through the GitHub authorization. SecOpsium should not be used to scan anything outside repositories the user owns or is explicitly authorized to assess.
The public security practices page describes the hosted GitHub workflow as GitHub App based, with short lived installation tokens used when a scan needs private repository access. Those tokens are scoped to authorized repositories and should not be treated like reusable personal credentials.
- Authorization happens through GitHub rather than pasted personal access tokens.
- Repository scope is selected by the user or workspace admin.
- Private repository scanning depends on the granted GitHub permissions.
- Revocation should happen through SecOpsium or directly through GitHub settings.
Why scoped access matters
Scoped access reduces unnecessary exposure. The product does not need a user's personal access token pasted into the dashboard to run normal GitHub-backed scans.
This also gives teams a familiar revocation path through GitHub if they want to remove access.
- Authorize only the repositories that should be scanned.
- Disconnect or revoke access when it is no longer needed.
- Keep repository ownership and assessment authorization clear.
Repository scope and roles
A workspace should connect only the repositories that need security validation. For a small team, that may mean a production API, frontend application, infrastructure repository, or library that handles credentials or customer data.
Workspace owners and admins are the right people to control repository linking because they are usually responsible for access boundaries. Regular contributors may still review findings or trigger scans where the product allows it, but integration control should stay with the people accountable for the workspace.
- Connect specific repositories when possible instead of granting broad access by default.
- Review GitHub access after team changes, project handoffs, or customer security reviews.
- Disconnect repositories that no longer need recurring validation.
- Treat scan access as a security integration, not as a casual developer convenience.
Private repository handling
Private repository access is sensitive even when source code is not retained as a product artifact. A scan may still process code, paths, findings, snippets, and security metadata during execution, so teams should connect private repositories deliberately.
SecOpsium should keep enough result context to help remediation, such as finding type, path, severity, evidence snippet, and guidance. It should avoid turning the SaaS into a long term store for full repository content.
- Private repository scans should run only after explicit authorization.
- Evidence snippets should be short and remediation oriented.
- Finding metadata can still be sensitive and should be protected.
- Access should be revoked when the team no longer needs the workflow.
Revocation and failure states
If GitHub access is revoked, repository permissions change, or the GitHub App is uninstalled, future scans may fail or lose visibility into repositories. That is expected and should be treated as an authorization state, not a scanner defect.
A failed authorization check should be communicated clearly so a user can reconnect GitHub, adjust repository access, or remove the project from the scan workflow.
- Revoked access should stop future scans for affected repositories.
- Permission errors should not be hidden as empty scan results.
- Teams should periodically confirm that connected repositories still match their intended scope.
- Security reviewers may ask for this access model before approving a tool connected to private code.
CLI transparency
The open-source CLI gives technical users a way to inspect local scanning behavior separately from the SaaS.
The CLI is useful, but the SaaS is still valuable because it adds hosted execution, team visibility, reports, and scan history.
For teams that are cautious about connecting a hosted product to private repositories, the CLI can be a useful first trust step. The SaaS remains the operational system for recurring scans, shared remediation, and report history.
Frequently Asked Questions
Can users control which repositories are connected?
Yes. Repository visibility depends on the scope authorized through GitHub. Teams should grant access only to repositories they want SecOpsium to assess.
Can GitHub access be revoked?
Yes. Users can revoke or disconnect the GitHub authorization when they no longer want SecOpsium to access the selected repositories.
Should every repository be connected?
No. Teams should connect only repositories they want SecOpsium to assess, especially when working with private code or sensitive projects.
What happens if GitHub access changes?
Future scans may fail or lose repository visibility if access is revoked, repository scope changes, or the GitHub App is uninstalled.