From repository connected to first fix shipped.
Practical guides for the people doing the work. How to connect your code, which languages we scan today, which clouds we cover, and how the GDPR Companion turns six questions into the documentation an auditor expects.
Getting started
Connect your first GitHub repository, run a baseline scan, and read your first plain-English finding. The whole flow takes about 90 seconds.
Scanning
How CyberDebunk detects vulnerabilities across your repositories, prioritises them by exploitability and impact, and explains each finding in plain English.
Auto-PR & remediation
Drafted pull requests with a recommended bump strategy, ready for your team to review, test, and merge. Manual remediation is also supported.
Cloud connections
Connect AWS via a read-only role to detect public exposure, misconfigurations, and drift. Azure and Google Cloud are in active development.
Compliance toolkit
GDPR Companion turns six plain-English questions into an Article 30 register, a DPIA, and a sub-processor change log you can show an auditor.
Notifications
Per-severity routing across email and Slack, plus an in-product inbox with daily and weekly digests, quiet hours, and per-project routing rules.
How a scan works
A scan completes in seconds, not hours. Here is the path from "connect this repo" to "fix is drafted".
You connect GitHub
Install the CyberDebunk GitHub app and pick the repositories you want monitored. Read-only access to dependency manifests, not your source code.
We map your stack
We detect the languages, package managers, container files, and infrastructure-as-code in each repository, then build the dependency graph.
We match against threats
Your dependency graph is matched against our continuously refreshed vulnerability database covering more than 300,000 known threats.
You get the fix
Plain-English findings, prioritised by exploitability and impact, with an auto-PR drafted for most dependency issues. Merge or close.
Languages and ecosystems we scan today
CyberDebunk inspects dependency manifests and lockfiles in the package managers your team already uses. Adding more ecosystems is one of our highest-priority workstreams.
How we connect to your code
Today we integrate with GitHub. GitLab and Bitbucket are on the roadmap. The principle is the same: read-only, scoped to manifests, never source code.
Install the CyberDebunk GitHub app on the organisation or repositories you want monitored. The app uses GitHub OAuth, requires only read access to dependency manifests, and can be removed at any time from your GitHub settings.
- Repository-level scoping, with branch protection respected
- Manifest-only access, your application source is never copied off GitHub
- Auto-PRs land as a clearly-labelled branch with a signed commit
- Remove or re-scope from GitHub settings at any time
GitLab self-hosted and Bitbucket Cloud are on the near-term roadmap. The integration model will mirror GitHub: read-only access to manifests, scoped per-project, with auto-PRs and easy revocation.
- GitLab support targeted for the next quarter
- Bitbucket Cloud to follow
- Want priority? Email [email protected] and we'll add you to the early-access list
Cloud integrations
CyberDebunk supports AWS today. Azure and Google Cloud are actively in development. All cloud connections use read-only roles, we never make changes to your infrastructure.
Read-only IAM role across S3, EC2, IAM, RDS, Lambda, and security groups. Detects public exposure, over-permissive policies, and configuration drift.
Azure subscription scanning is being built. Sign up to the early-access list to be notified when it ships.
GCP project and organisation scanning is on the roadmap, with workload-identity federation as the planned auth path.
Cloudflare, DigitalOcean and others are on the longer-term roadmap. Tell us which one you need at [email protected].
Compliance frameworks we support
We focus on GDPR and SOC 2 in the product today. NIS2 and additional evidence pipelines may follow once we can support them end-to-end, we will not announce them as supported until they really are.
Six plain-English questions generate an Article 30 register, a DPIA, and a sub-processor list. Re-validation runs whenever your stack changes.
Checklists and evidence exports mapped to Trust Services Criteria. Use them alongside your own auditor engagement.
Readiness scoring and BSI-aligned reporting templates for European essential and important entities.
Common questions
Do you read my source code?
No. The scanner only inspects dependency manifests, lockfiles, container files, and infrastructure-as-code. Application source code is never copied to our servers, and the GitHub app's permissions reflect that.
How often is the vulnerability database refreshed?
Continuously. New threats from public vulnerability feeds typically appear in your dashboard within minutes of public disclosure. Threats actively exploited in the wild get an additional priority pass.
Which languages do you support today?
JavaScript, TypeScript, Python, Go, Java, Kotlin, Ruby, Rust, PHP, and C# / .NET, plus container images (Dockerfiles and base layers) and infrastructure-as-code (Terraform, CloudFormation). More on the way.
What clouds do you support?
AWS today, with Azure and Google Cloud in active development. Cloud connections use read-only roles only, CyberDebunk never makes changes to your infrastructure.
What about SOC 2 evidence?
The compliance toolkit covers GDPR end-to-end and includes SOC 2-oriented checklists and exports. If you need a specific evidence format for your auditor, email us, we are happy to prioritise based on real customer demand.
Where is my data hosted?
European cloud infrastructure, by default. We host customer data in the EU and never move it without your explicit consent. For residency, sub-processors, and retention, see our Privacy Policy.
Team invites — how they work
Who sends an invite. Only the project owner can invite collaborators. Invites are sent per project (not a separate “organisation” layer yet).
API (authenticated, owner only). POST /api/projects/<project_id>/invites/ with JSON {"email":"[email protected]","role":"member"} (role: member or admin). The API emails a signed link to /accept-invite?token=… (14-day expiry).
Accept flow. GET /api/projects/invites/preview/?token=… returns safe metadata (project name, inviter, role, expiry). POST /api/projects/invites/accept/ with token, password, password_confirm, first_name, last_name creates the account (email pre-verified from the invite) and adds a ProjectMember row. If the email already has an account, sign in first, then open the same link with a valid JWT so the membership can be attached.
Decline. POST /api/projects/invites/decline/ with {"token":"…"}.
Settings UI. In the app, open Dashboard → Settings → Team, pick the project, enter the colleague’s email and role, then Send invitation. That calls the same POST /api/projects/<id>/invites/ endpoint as above.
Enterprise SSO (SAML 2.0)
CyberDebunk acts as a SAML 2.0 Service Provider (SP). Users click SSO / SAML on the sign-in page; the browser is redirected to your IdP (Okta, Azure AD, Google Workspace SAML, Keycloak, etc.); after authentication the IdP POSTs a SAML assertion to our Assertion Consumer Service (ACS) URL; we validate the assertion, read the NameID / email attribute, and issue the same JWT session as password or social login.
URLs to register at your IdP.
- ACS (Assertion Consumer Service):
https://<api-host>/api/auth/sso/saml/acs/— binding HTTP-POST. - SP metadata (for admins):
https://<api-host>/api/auth/sso/saml/metadata/ - SP-initiated login entry:
https://<api-host>/api/auth/sso/saml/login/(linked from the product sign-in page).
Environment variables (API server). Set SAML_IDP_METADATA_URL to your IdP’s metadata URL, and SAML_SP_X509_CERT / SAML_SP_PRIVATE_KEY to a dedicated key pair used to sign AuthnRequests (PEM format). Optionally set SAML_SP_ENTITY_ID (defaults to the metadata URL) and SAML_SP_PUBLIC_BASE_URL if the API is behind a reverse proxy and request.build_absolute_uri would not match the public URL.
Typical IdP configuration. Create a SAML “enterprise application” / app integration, upload our SP metadata or paste ACS + Entity ID manually, map the SAML NameID or email attribute to the user’s work email, and release that attribute to this SP.
Sign-up form: which fields go to the API?
“Register” means the public endpoint POST /api/auth/register/ (same as “create account”). It persists a row in the authentication_user table: email, password (hashed), name (from first and last name at signup), and company_name.
First name, last name, and company on the marketing sign-up form are now included in that request so product and support context stay aligned with what the user typed.