Cloud
Cortex Cloud
Durable managed execution, validation and release evidence connected to a Cortex session.
Cortex Cloud provides managed project execution connected to a Cortex session. It lets eligible work continue with the selected project revision, objective, approvals and progress available to the originating client.
Get started
Section titled “Get started”- Enable Cortex Cloud.
- Decide whether the task should remain local or move to Cloud.
- Prepare and approve a handoff.
- Follow progress and results.
Project-aware execution
Section titled “Project-aware execution”Cloud prepares an authorized project workspace for the task. Work is tied to a particular revision so that a build, test or security result can be interpreted against the code that produced it. This gives remote work a concrete project context even when the request begins in a browser or on mobile.
Choose Cloud when an eligible task needs a managed execution environment. Local execution remains useful when the work depends on the connected development machine. Local versus Cloud explains the choice and preparation requirements.
Validation capabilities
Section titled “Validation capabilities”| Target | Product outcome |
|---|---|
| Plan | Detected project context and proposed validation commands |
| Test | Managed build and execution of planned tests |
| Runtime | Application startup, readiness and bounded health observations |
| Security | Runtime verification and eligible security assessment |
| Secure release | The eligible validation stages and release-evidence path |
A task may require only a plan or may proceed to deeper validation. Detected project commands, available tools and organization policy determine the supported path. See validation targets for target selection and runtime settings.
Runtime and security assessment
Section titled “Runtime and security assessment”Runtime verification checks whether the built application starts and meets the configured readiness conditions. Eligible security assessment adds bounded checks against that runtime, including supported discovery, passive analysis, HTTP checks and API coverage.
These stages produce observations about the assessed application and scope. They complement source and dependency reports in DevSecOps. The runtime security guide describes the approved scope and interpretation of results.
Progress, artifacts and release evidence
Section titled “Progress, artifacts and release evidence”Cloud tasks expose progress and stage outcomes, including failures, skipped checks and available artifacts. Users can follow the work from supported Cortex clients instead of leaving the outcome attached only to the machine that initiated it.
Release evidence packages eligible validation results, artifacts, provenance and review state for a specific revision. An evidence preview shows the requested scope and requirements before submission. Review and approval refer to the resulting digest; later changes need evidence for the new revision. See release evidence.
When managed execution is useful
Section titled “When managed execution is useful”Cloud is useful when eligible project work should not depend on one open editor or the continued availability of a developer’s machine. A request can begin in VS Code, a browser or mobile, reach a managed project workspace and return progress through the same connected Cortex task.
The user chooses Local or Cortex Cloud; the platform handles eligible managed workspace placement. Project handoff is grounded in a stable committed revision. A Cloud selection does not authorize local commands as an automatic fallback when the remote destination is unavailable. Preparation, policy or capacity problems should produce an understandable state and next step.
Source, dependency and secret assessment
Section titled “Source, dependency and secret assessment”Before application execution, eligible Cloud workflows can inspect project metadata, source, manifests, lockfiles, CI configuration and container definitions. Static analysis, dependency checks and secret scanning examine risks visible before the application starts. Planning identifies the supported validation path; it is distinct from running repository code.
Use those findings together. A source issue points to an implementation risk, a dependency issue concerns a component used by the application, and a secret finding concerns exposed sensitive material. None is a substitute for testing the application’s behavior.
From an approved plan to a running application
Section titled “From an approved plan to a running application”An eligible build creates a controlled validation image corresponding to the selected revision and plan. Planned tests run in an isolated environment and return outcomes that distinguish product failures from dependency, environment or resource problems. Runtime verification then checks startup, readiness and health before deeper behavior assessment.
The sequence is deliberate: the evidence for a later stage must belong to the same candidate as the earlier stages. A result for another revision or image does not establish the condition of the current release.
Runtime coverage and its limits
Section titled “Runtime coverage and its limits”Supported assessments can combine scoped discovery, passive web analysis, curated HTTP checks and API examples or coverage testing. They observe an isolated validated application under the enabled assessment profile and resource limits. Discovery identifies reachable resources; behavior checks provide observations about how the target responds.
A clean assessment means no issue was found by the supported checks within their scope. It does not mean every endpoint, input or attack path was tested. Unsupported configurations and incomplete stages remain visible. Findings provide evidence for review, not permission to change source or deploy.
Reviewable release records
Section titled “Reviewable release records”Eligible release evidence can combine source and dependency findings, secret checks, build and test records, runtime observations, an SBOM and provenance. Integrity data and signed attestations, where produced, support separate verification of the packaged artifacts.
Review the scope, candidate revision, stage outcomes and remaining gaps before approving a release. Cloud Workflows in the DevSecOps Task Center provides another view of durable state and outcomes. A cancelled or partially completed workflow is not the same as a validated release.
Product background
Section titled “Product background”Access and availability
Section titled “Access and availability”Cloud requires an eligible account, authorized project and available execution capacity. Organization controls determine enabled targets, approvals, budgets and artifact handling. A partial or skipped stage remains visible and does not establish that the corresponding check passed.
Run Cloud work covers preparation and handoff, and Account & Billing covers shared plan and entitlement management.