SecOps
The SecOps app
SecOps is Solidafy's app for security findings. It puts the open findings from your security tools in one place, gives each one an owner team and a deadline to fix it (its SLA), groups them into the fixes that clear them, and files one Jira ticket per fix. This page covers setting it up, every page of the app, its settings, and how to reach it from an AI agent.
Before you start
SecOps is one of the portal's apps. It opens from the Apps section of the sidebar, which appears once Solidafy has switched apps on for your organisation.
SecOps is open to environment owners and admins. Anyone else who opens it sees a message saying so. If SecOps isn't installed in the environment yet, an admin sees Install first.
Setting it up
After installing, SecOps shows Your security findings in one place with two ways in. Whichever you pick, you can change it later in Settings.
Use your existing security data
Pick this when your environment already builds a findings table. SecOps matches each part of the app to a table you already have, by its columns, and preselects the best fit. You can pick another table that fits, or leave out an optional part:
| Part | What the table holds | Required |
|---|---|---|
| Findings | One row per finding, with at least a reference, severity, title, target, when it was found, and whether it is still open. CVE, CVSS, EPSS, package and fix columns are read when present. | Yes |
| Updates | Status changes people made to findings, with the status and when. | No |
| Repo owners | Which team owns each repository. | No |
| Cloud owners | Which team owns each cloud target, such as a resource group or subscription. | No |
| Exploit data | The EPSS exploit chance for each CVE. | No |
Next to each table, Start says how many rows it holds and when it was last written. SecOps reads these tables as they are and never changes them or the pipelines that build them.
Start from scratch
Pick this when you have no findings table. You pick the tools SecOps reads, and it builds its own findings from them.
SecOps builds findings from GitHub: Dependabot alerts and code scanning alerts. It reads GitHub through the same connector Engineering Delivery uses, so one GitHub connection serves both apps. The token is a GitHub personal access token (classic) with the repo, read:org and security_events scopes.
If GitHub isn't connected yet, Connect GitHub opens the same form as Data Sources, with step-by-step help for making the token, and the connection is saved there. If you can't manage data sources, the screen says that someone who can needs to connect it.
The Start screen also lists Snyk, Azure Defender, external scanning, and EPSS and NVD, marked Coming later. To see findings from those tools today, build a findings table from them and use the first way in.
What it builds
Either way, SecOps builds its own tables in the app_secops namespace and keeps them fresh: a change shows up within the hour.
The pages
The rail on the left and the tabs at the top hold five pages.
| Page | Title | What it answers |
|---|---|---|
| Overview | Security this week | How many findings are open, how many are past their SLA, and where they come from. |
| Findings | Open findings | What exactly is open, and what to do about each finding. |
| Remediation | Remediation | Which kinds of change clear the most findings, and are we fixing faster than we find? |
| Tickets | Tickets | Which fixes have a Jira ticket, and where is each one? |
| Settings | Settings | SLAs, owner rules and Jira projects. |
Filters
Every page except Settings starts with the same filters: Repo or target, Owner team (including No owner yet), Source and Severity (Critical, High, Medium, Low or Info). They stay in force as you move between pages.
Overview
Overview opens with this week's security update in a sentence or two, then the key numbers, each against four weeks back:
- Open findings and Critical and high.
- Breaching SLA: open findings past their SLA, with a goal of 0.
- Likely exploitable: findings whose EPSS exploit chance is over 50%.
- No owner: the share of findings with no owner team, with a goal of under 10%.
- Average age of open findings.
Each number opens the findings it counts. Below them, Open findings breaks the open findings down By source or By owner team, with how many are past their SLA. Each bar opens those findings.
Findings
Findings lists what is open, 25 at a time. At the top:
- Search: by title, CVE, package or target.
- Show: Grouped by fix (one row per change that clears several findings), Grouped by vulnerability (one row per CVE, or per title when there is none), or Every finding.
- Sort: most urgent first, by severity, oldest first, or, for groups, biggest first.
Opening a group lists its findings. Opening a finding shows what it is, how to fix it (with a link to its remediation workstream), and its facts: source, CVE, weakness, package, the version it is fixed in, CVSS, EPSS exploit chance, when it was first seen, its SLA, and how many scans have seen it.
Each finding also has an Update box, where you set its status and a note:
- New, Triage or In progress while it is being worked on.
- Risk accepted or False positive for an exception. An exception has a Recheck on date: on that day the exception ends and the finding reopens with its SLA restarted. A risk acceptance lasts at most 180 days.
An update is saved for everyone at once and reaches the numbers within the hour. A finding counts as fixed when the scanner stops reporting it.
Remediation
Remediation has three views:
- Plan: one workstream per kind of change (Update dependencies, Fix cloud configuration, Rebuild container images, Harden external hosts, Patch hosts, Fix code, and Other fixes), with how many open findings each clears, how many are past their SLA, and how many distinct fixes it takes. Opening a workstream shows its five biggest fixes.
- Progress: fixed and new findings in the last 30 days, the median time to fix, the share fixed within the SLA, new against fixed each week, time to fix against the SLA by severity, and a scorecard of the teams with the most open findings.
- Exceptions: every risk acceptance and false positive, with why, who approved it, and when it is checked again. Exceptions past their recheck date or with no recheck date are counted separately.
Tickets
Tickets lists every fix, the most urgent first, with its findings, its SLA, its team and where its Jira ticket is: Not filed, On its way to Jira, or its Jira key and status. File ticket files one ticket for the fix, listing its findings, in the Jira project Settings maps its team to. It reaches Jira within the hour.
Filing needs Jira connected for sending (see Settings below).
Settings
Settings has three sections. You change them as one draft: a bar at the bottom counts your changes, Discard throws them away, and Review and apply lists each change before you Apply it. Findings take the new settings on the next run, within the hour.
- Time to fix, by severity: the SLA in days for Critical, High, Medium and Low findings. Each field shows its default. Info findings have no SLA.
- Owner rules: give every finding on a repo or target an owner team. A rule comes before any team the findings themselves name. You pick the repo or target and the team from lists, and before you add the rule SecOps previews how many open findings it takes and which teams they belong to before the rule. Teams come from the findings and from Engineering Delivery's people and teams.
- Jira tickets: which Jira project each team's tickets go to, and a project for Any other team. SecOps uses two Jira connections, both of which you can connect from here: one to read Jira's projects and the tickets it filed, and Jira for sending to file tickets. The sending account needs Browse projects, Create issues and Add comments in each project. If Jira is connected but SecOps doesn't read it yet, Set up Jira sync sets that up.
Alerts and Scout
SecOps raises alerts in your portal notifications when a team has open findings past their SLA, and when a vulnerability is open with a high chance of being exploited. Each alert is raised once and only raised again after it clears.
When you start SecOps, it installs an operator called Scout, which you find under Workspace > Operators. Once a week, every environment admin gets a short triage note in their notifications: what is open against four weeks back, what is past its SLA, the most urgent fix, and the findings likely to be exploited or owned by no team.
Using SecOps from an AI agent
SecOps answers three tools on the MCP server's Data Explorer address, for people who can open the app. They read the same data as the screens, as you:
| Tool | What it answers |
|---|---|
get_security_overview | Open findings this week: how many, past their SLA, critical or high, likely exploited, with no owner, and by source and team, each against four weeks back. |
list_urgent_fixes | The most urgent fixes first, each with how many open findings it clears, the worst severity and the days to its SLA. |
get_security_finding | One finding by its reference (ref): what it is, where, its severity, CVE and exploit chance, its SLA, how to fix it, and its status or exception. |
They take the same filters as the screens: team, source, severity and target. See AI agents and MCP for connecting an agent.
Uninstalling
At the bottom of Settings, under Danger zone, an environment admin can choose Uninstall app. SecOps first lists everything it will remove: its operator and schedules, its pipelines and their runs, its tables, and its saved settings and records. You type SecOps to confirm. The data sources SecOps created are kept unless you tick Also remove the data sources this app created, and data sources you created yourself are never removed. Afterwards the app opens on its Start screen again.