Application risk & remediation
Give every finding an application, an owner and a next step.
An enterprise portfolio needs more than a severity total. Code Security lets teams organise repositories into applications and review the findings attached to the services they operate. Risk views, ownership, SLA policy and remediation records help the security team turn a large queue into work an application owner can act on.
Application
Customer checkout
One service owner. Evidence from each participating repository.
- Web frontendSource findings & dependencies
- Payments APIFindings, dispositions & due dates
- InfrastructureConfiguration & delivery checks
Example relationships, not a customer dashboard. Repository membership is configured by your team.
01 / Application risk & remediation
Make the application the unit of accountability
A customer-facing service may contain an API, web frontend, shared library and infrastructure repository. Grouping those repositories lets a reviewer assess the work as one application while preserving the source repository and finding evidence underneath.
Use the application view to compare open findings, known-exploited context, overdue work and scan freshness. A service with a stale scan needs a different response from a service with a newly introduced high-impact issue. Portfolio views reflect uploaded evidence and configured context, not an independent inventory of every system the enterprise owns.
02 / Application risk & remediation
Move from a risk queue to a recorded decision
Risk management supports investigation, assignment and a reasoned disposition. Teams can record an acceptance for review, follow its expiry and keep governance decisions distinct from an engineer's local annotation. The underlying finding remains part of the record.
SLA policy gives an organisation a shared way to set remediation expectations. Campaigns and reporting help coordinate related work across repositories. The meaningful outcome is an accountable action with evidence, a due date where applicable and a subsequent verification, rather than a lower score without an explanation.
03 / Application risk & remediation
Use trends to understand what is changing
Dashboard severity, surface breakdowns and historical views give the team a way to distinguish a growing backlog from changing scan coverage. Read new, open and resolved findings alongside the repositories that participated and the dates of their scans.
Business and Enterprise add organisation governance features such as the audit log, custom upload policies, signed webhooks and scheduled reports. Configure integrations around the team's existing delivery process and use organisation roles to decide who may change policy or approve a risk decision.
Reviewable output
The information behind the next decision.
Group repositories into applications, prioritise uploaded findings, define SLA policies and keep risk decisions with their evidence.
| Question | Where to look | Action |
|---|---|---|
| Which service needs attention? | Applications, open findings and available risk context | Assign the relevant application owner |
| What is overdue? | Configured SLA policy and remediation records | Investigate overdue work and record an agreed response |
| Why is a finding still open? | Disposition, comments and acceptance history | Check the reason, reviewer and any expiry |
| Did exposure actually fall? | Comparable scans, coverage and inventory changes | Verify the remediation and refresh stale repositories |
Put it to work
Make review part of the team's working process.
Define the portfolio
Map repositories to applications, identify their owners and agree the criticality and context the organisation will maintain.
Set a remediation policy
Define SLA expectations and use roles and governance workflows for exceptions. Make expiry and review responsibility explicit.
Review a service, then verify progress
Work from the application into the actual finding, run remediation and rescan. Use trends and reports to check what changed and what remains unassessed.
magdox scan --full --repository billing-service --upload .After an authorised upload, organise the repository and its findings in the console. Application membership, SLA policy and organisation approvals are managed on the server; a local CLI flag cannot grant those permissions.
Before you start
Scope and practical questions.
Can a local risk assessment approve an organisation exception?
No. Local risk labels are separate from server-side governance, membership and approval. They do not change organisation permissions or waive the configured severity gate.
Which plans include these controls?
Application risk management, organisation inventory and the governance features described here are part of Business and Enterprise. The pricing comparison separates them from the findings workflow included in Team.
Explore Code Security
Source-code analysis
Local SAST with affected locations, supported flow evidence, severity, confidence and explicit analysis coverage.
Dependency security
Review known vulnerabilities, malicious-package indicators and unresolved dependency versions from the repository's own manifests and lockfiles.
Secrets & configuration
Review source, infrastructure definitions and delivery configuration locally, with redacted secret findings and file-level context.
Code Security · next step
Evaluate the workflow on your own code.
Use a repository your team understands, review the findings with its engineers and decide how the result fits your delivery process.
14-day self-service trial. Card required; cancel before the trial ends to avoid the first charge.