Security Management delivers the full lifecycle of platform security operations from a single console. It runs vulnerability scanning across the application's own code, its dependency tree and its configuration, surfacing weaknesses with a severity rating, an affected component and a reproducible description. It performs structured security auditing against a defined control catalogue covering dependencies, secrets, authentication, authorisation, injection, dangerous execution patterns, input validation, network posture and server-side request exposure. Every weakness becomes a tracked finding with an owner, a severity, a status and a remediation record, so nothing is discovered and then quietly forgotten.

Beyond detection, the module manages remediation tracking and hardening as first-class work. It maintains the platform's security headers, content security policy, cookie protections, rate limits and transport rules as governed configuration, verifies that they remain in force, and flags any drift. It inventories the dependency estate, correlates it against published vulnerability advisories, and distinguishes runtime exposure from development-only transitive risk so that effort concentrates where it matters. Secrets hygiene, credential rotation schedules and pre-release readiness checks are held and reported here, giving the security function one authoritative place to see posture, progress and residual risk.

At the centre of the module sits the finding: a single, verifiable security observation about the platform. A finding carries a severity, a category, a description of the weakness, the component it touches, and a lifecycle that runs from discovery through triage, remediation and verification to closure. Findings are the currency of the module, and almost everything else exists to produce, resolve or account for them.

Findings are grouped by the scan that produced them. A scan is a point-in-time examination of the platform, dated and attributed, against which findings are recorded so that posture can be compared over time and progress measured between one examination and the next. Scans give the security team a defensible timeline: what was known, when, and how quickly it was addressed.

Each finding is assessed against a control, the tested expectation of secure behaviour drawn from a recognised control catalogue. A control expresses what good looks like in an area such as authentication or injection resistance, and a finding is the record of a place where reality falls short of it. Sitting across all of these is the platform's hardening baseline: the governed set of protective settings, from headers and content security policy to cookie flags and rate limits, that the module continuously affirms. Findings, scans, controls and the baseline relate simply. A scan tests the estate against controls, raises findings where controls are unmet, and closes them once the baseline and the code once again satisfy the control that exposed them.

The core loop is scan, triage, remediate, verify. A scan runs, whether on a schedule, on a code change, or on demand, and produces a set of findings ranked by severity. Security staff triage the queue, confirming genuine risk, dismissing accepted or non-exploitable items with a recorded rationale, and assigning owners. Each finding then moves through remediation, where the fix is implemented and linked, and into verification, where a follow-up scan or a manual check confirms the weakness is closed rather than merely reported closed. The finding's history preserves every transition, so an auditor can reconstruct exactly how any given risk was handled.

A parallel workflow governs hardening and readiness. The module holds the platform's protective configuration as a baseline, checks the live system against it, and raises a finding whenever a setting is missing or weakened. A dedicated pre-production readiness workflow drives the checklist that must be satisfied before any environment is exposed: example configuration completeness, credential rotation, seed and default hygiene, secret-scanning guards and a defined production secrets strategy. Each item is tracked to completion with evidence, so promotion to production is a gated, recorded decision rather than an assumption.

The module's value lies in the rigour of its control coverage. On dependencies it maps the full package tree against vulnerability advisories, separates runtime from development-only exposure, and drives upstream replacement of unmaintained or vulnerable libraries. On authentication and authorisation it verifies session protections, token lifetimes and cookie flags, and confirms that every mutating route enforces an explicit permission check under the platform's attribute-based access model, treating any unguarded or unintentionally public route as a finding. On injection it audits every dynamic query path for safe-identifier validation and parameterisation, and every rendering path for cross-site scripting, requiring safe DOM interfaces in place of raw markup insertion.

It enforces input validation as a universal guard on mutation endpoints, with schema-based validation for structured payloads, and ensures that error responses return generic messages rather than leaking database or stack detail to clients. On network posture it maintains a complete set of security headers, a content security policy, rate limiting on sensitive endpoints such as authentication, and controls against server-side request forgery where the platform makes outbound calls. Severities follow a critical, high, medium and low scale with clear remediation expectations at each level, and the module reports the standing tally, so leadership can see at a glance that critical and high exposure is held at zero and that lower-severity items are either resolved or formally acknowledged with justification.

Security Management is woven into the platform it protects. It draws directly on Role Management and its attribute-based access model to audit the authorisation surface, checking that permissions are declared and enforced consistently across every subject and route. It feeds and reads System Management, using the platform's audit and error logging and health signals as evidence, and treating backup, restore and regional configuration as part of the estate it hardens. Its findings and readiness state flow to Governance, Risk and Compliance, where a proven technical control becomes evidence against a regulatory obligation, keeping the organisational and platform views of assurance in step without duplicating work.

Alerting runs through the Notification Engine, so a new critical finding or a failed hardening check reaches the right people on the right channel immediately. Remediation work is coordinated through Flow Management for approvals and hand-offs, credential and secret governance aligns with Data Management and the platform's data stores, and the module's oversight of outbound integration endpoints connects it to Connector Management. The result is a security function that is not bolted on but native, seeing the same modules, data and users that everyone else does.

AI Workers are first-class participants in Security Management, not an assistant layered over it. A security officer can query the module conversationally, asking which high-severity findings remain open, which routes lack an explicit permission check, or how remediation velocity has moved since the last scan, and receive answers drawn from live module data. Workers execute actions within their granted permissions: launching a scan, triaging a finding, assigning an owner, or updating the hardening baseline, each action recorded to the same history as any human's.

They watch continuously for anomalies and exceptions, flagging a newly published advisory affecting an installed dependency, a configuration that has drifted from the baseline, or an unusual pattern in authentication attempts, and raising it through the Notification Engine before it becomes an incident. Workers perform extraction and interpretation, reading advisory text, dependency manifests and scan output to enrich a finding with affected versions, exploitability and a proposed fix. They provide decision support by proposing severity, correlating related findings and drafting remediation plans. Crucially, an AI Worker serves as a review or approval node in the module's workflows, signing off a routine hardening change or verifying that a remediation genuinely closed its finding, while escalating anything material to a human, so security throughput rises without loosening control.