From a connected request to evidence about the software that runs
Cortex Cloud gave users a choice between working locally and sending eligible work to a managed cloud workspace. A request could begin in Visual Studio Code, a browser, or on mobile, continue remotely, and return progress and results through the same Cortex workflow.
This release extends that foundation into static analysis, software validation, and runtime security assessment. Cortex Cloud can examine an eligible project, run source and dependency checks, build a controlled validation image, execute its planned tests, verify that the application starts and remains healthy, and assess its behavior in an isolated environment. Each stage is tied to the same project revision and produces evidence that the next stage can check.
That connection matters. A security result is more useful when a team can answer which code revision produced it, which image was assessed, whether its tests passed, what the application did while running, and whether the result belongs to the workflow the user actually requested.
One workflow, several kinds of evidence
Static inspection and runtime assessment answer different questions.
Before running application code, Cortex Cloud can inspect project metadata and source to determine how a repository should be validated and where risks may exist. This includes manifests, lockfiles, relevant CI configuration, container definitions, and available test evidence. Static analysis, dependency checks, and secret scanning examine risks visible before the application starts. The validation plan is tied to an immutable source revision and a digest of the evidence used to create it. Ambiguous or unsupported configurations are reported rather than guessed.
The build stage applies further policy checks to the proposed validation image. It checks that the build still corresponds to the approved plan and repository evidence, evaluates the container definition against Cloud policy, and records the identity and provenance of the resulting image.
Execution then supplies a different view. Planned tests show whether the application meets its own test expectations. Runtime verification shows whether the validated image can start, become ready, and remain healthy under a defined contract. Runtime security assessment observes an isolated running target and reports findings from bounded discovery, passive analysis, selected HTTP checks, and API examples and coverage testing.
These stages form a connected path:
Project revision → static assessment → validation plan → qualified image → offline tests → runtime verification → security assessment → release evidence
A later result cannot simply refer to a similar image or a newer version of the repository. Cortex Cloud checks the relationship among the owner, workspace, revision, plan, build, validation run, and runtime specification before admitting the next step.
Validation before behavior scanning
Runtime findings are easier to interpret when the target is known to be the intended application.
Cortex Cloud begins with a deterministic validation plan. It selects tests from repository evidence and records requirements that affect whether those tests can run. It also identifies when a repository needs a supported container definition. Planning itself does not execute repository code.
A dedicated build stage then creates and qualifies an immutable image. It checks for changes in the source evidence or plan before building, applies limits to the build context, and records the image and its provenance. The image is passed to the validation environment as a digest-checked artifact.
The planned tests run in an ephemeral, offline container. Cortex Cloud records their outcome, duration, exit status, bounded output, and digests of the complete output streams. Failures are classified so a team can distinguish, for example, a product test failure from an unavailable dependency, a resource limit, or an environment problem.
A passed test run is a prerequisite for runtime verification. At that stage, the application is started with a narrow contract: a declared port, an HTTP or TCP readiness check, and bounded startup and observation periods. Cortex Cloud records readiness, continued health, exit state, resource observations, and the constraints under which the application ran.
This sequence gives users more than a green or red badge. It gives them a traceable account of what was assessed and where a failure occurred.
Assessing the application while it runs
The new runtime security workflow adds four complementary forms of assessment.
- Scoped discovery maps reachable resources on the running application within a fixed target and request budget. It helps identify the routes the application actually exposes.
- Passive web analysis observes responses and reports issues detectable without an active attack sequence.
- Curated HTTP checks evaluate the running target against a restricted set of security checks.
- API examples and coverage testing exercises supported behavior described by the application’s API specification.
Together, these assessments can reveal behavior that source inspection alone may miss: an unexpected reachable route, an unsafe response, a security issue visible only after the application starts, or a mismatch between an API description and observed behavior.
The assessment is deliberately bounded. It runs against a fresh instance of the validated image on an internal network, without published host ports or external network access. The caller chooses supported assessment types and a quick or standard profile; the workflow supplies the remaining limits. Results are normalized, redacted where needed, fingerprinted, and correlated into one assessment with severity counts and discovery evidence.
A finding remains evidence for review. Cortex Cloud does not treat a scan result as permission to edit the repository or deploy a change.
Static and runtime coverage in one release view
Cortex already brings security review and scanning into its wider developer experience, described across the Cortex blog collection. Cortex Cloud extends that experience with managed, revision-bound static and runtime assessment. Source analysis can identify risky code patterns, exposed secrets, and vulnerable dependencies. Repository and build policy checks examine whether the project can be validated safely. Runtime assessment then checks what the built application actually exposes and how it responds.
These checks complement one another. A dependency finding identifies a risk in the materials used to build software. A source finding points to a potential flaw before execution. A runtime finding shows observable behavior in the running application. Their shared release identity lets a reviewer compare them against the same candidate rather than reconcile disconnected reports by hand.
Coverage is explicit. A clean assessment means the supported checks found no issue within their defined scope. It is not a claim that every endpoint, input, configuration, or attack path has been tested.
Evidence that follows the release
A secure release workflow brings the Cloud stages together under one release identity. That identity binds the responsible user and workspace to the final source revision, repository tree, workflow plan, and verification attempt. Before collection, Cortex Cloud can estimate whether the requested work fits the available operation and cost limits.
The resulting evidence package can include:
- Static analysis, dependency, and secret scan results associated with the release candidate.
- Normalized records for the build, test run, runtime verification, and security assessment.
- The source revision, plan, configuration, image, and artifact digests that connect those records.
- Runtime findings, discovery resources, assessment constraints, and severity counts.
- A software bill of materials and release provenance.
- Artifact integrity checks and signed attestations that can be verified separately.
This gives reviewers a way to follow a claim back to the exact assessed artifact. It also helps prevent a common release mistake: combining a test result from one revision, a runtime result from another image, and a security summary from a different attempt into a single reassuring status.
Cortex workflows across devices
The execution environment may be managed, but the user’s work still begins wherever the issue appears.
Cortex Connect carries the objective, progress, and control between connected experiences. A developer can start an investigation in Visual Studio Code, check its progress in a browser, and review the result later on mobile. A security professional can identify a concern away from the desk and continue the project-aware workflow through the connected Cortex experience.
Cortex Discover adds a dedicated agentic AI browser to that picture. It can help users work with current pages and selected tabs, understand changing browser state, and connect research or an observed issue to a development task. An issue noticed while reviewing documentation, a dashboard, or a pull request can become an eligible Cortex Cloud validation request without forcing the user to reconstruct the objective in a separate tool.
The surfaces have different roles. Visual Studio Code keeps developers close to project work. Cortex Discover brings browser context and controlled browser action into the workflow. Mobile keeps progress and decisions accessible. Cortex Connect maintains continuity, while Cortex Cloud performs eligible managed execution and returns evidence to the connected task. The broader Cortex experience spans browser extensions, Visual Studio Code, Android, iPhone, and Cortex Discover.
From a scan result to a reviewable decision
Security teams rarely need another isolated list of findings. They need to know what was tested, whether the target was healthy, how the finding relates to the release candidate, and whether the evidence is complete enough for a decision.
Cortex Cloud now provides a stronger path to that answer. Static analysis and repository inspection establish risks visible before execution. Its validation workflow establishes the project and image under assessment. Runtime verification checks that the application can operate under the defined conditions. Behavioral assessment examines the running application within a constrained scope. Release evidence binds the outcomes to the final revision.
That is the next step for managed execution in Cortex: a request can move across devices, run in Cortex Cloud, and return with a record of what happened. Users remain connected to the work. Reviewers can inspect the evidence. Teams can decide what to fix, what to test further, and whether the release is ready.
