Setting up SecOps

An environment owner or admin starts SecOps by selecting vulnerability data and, optionally, access providers. This guide explains the two findings paths, what each connection adds and when the results refresh.

Choose how to start

After installation, Your security findings in one place offers:

• Use your existing security data: adopt a table already built in the environment.
• Start from scratch: connect supported security tools and let SecOps build the findings model.

Connecting a new source also requires permission to manage Data Sources. The connection forms explain the credentials and permissions they need.

Use your existing security data

SecOps matches tables by their columns and suggests the best fit. Read each match and its row count and write time before starting.

Optional finding fields add CVE, CVSS, weakness, package, remediation and exploit information when supplied. A matching schema does not prove that a table is complete or current. Confirm that its pipeline runs and that its status and severity words mean what you expect.

SecOps reads adopted tables without changing the source pipelines. It builds its own derived app tables. Unrecognised imported update statuses appear as Unknown status and are outside the open counts. Normalise unfamiliar words in your source data rather than assuming they behave like New or In progress.

Start from GitHub

GitHub is the findings source currently supported from scratch. SecOps reads Dependabot alerts and, if enabled, code-scanning alerts. Code scanning is selected by default, can be turned off, and needs the required GitHub Code Security access on the repositories.

Follow the in-app guide while signed in as an organisation owner. Create a fine-grained personal access token with your organisation as Resource owner and read-only permissions:

The organisation permissions and repository Administration support account access, audit events and deploy keys when GitHub is selected as an access source. Select the intended organisation as resource owner and the repositories the app should read. The guide recommends all repositories so future repositories are included.

Token acceptance alone does not prove every permission is present. An empty alert list or missing deploy keys can result from insufficient permissions. Organisation audit logs require GitHub Enterprise Cloud. Follow the form's steps and use GitHub's fine-grained token documentation for account and organisation policy details.

Snyk, Azure Defender, external scanning and EPSS/NVD are shown as planned scratch tools. To use findings or EPSS from those sources now, provide suitable tables through the existing-data path. GitHub scratch findings do not automatically gain an EPSS probability.

Add access sources

Settings → Access log sources supports Google Workspace, GitHub, Bitwarden, Scaleway, OVHcloud and Tailscale. Select the sources explicitly, even when a source is already used for findings. SecOps can connect or complete one from the same screen.

Google Workspace supplies directory people. Other providers supply their own accounts and events. Use the provider-specific read-only connection steps in the app: providers differ in available roles, credentials and audit history. Access explains the resulting evidence and its limits.

When does the data refresh?

The generated schedules run daily:

GitHub's findings model rebuilds after its Dependabot pull succeeds. These times are starts, not delivery guarantees. A failed or partial run, source permissions or a long pull can delay results. Source pipelines you adopt have their own schedules too.

Setup also attempts to start initial runs immediately. If an initial run cannot be started, the schedules pick it up, so a successful setup does not guarantee that its first data has already arrived.

Finding updates are saved immediately for other readers, but derived counts and reports change after the model rebuild. A queued Jira request waits for its sync. Avoid treating daily data as a live incident feed.

Check the first results

Confirm owners and deadlines, inspect a representative finding from each source, and compare a sample with the provider. Then check access coverage and unknown MFA values. Configure Jira routing only after the teams and fallback project make sense.

If results are missing, inspect the selected source, connection permissions, last successful load and expected table fields before concluding that there are no issues.