ARES / CI/CD SECURITY
Review the code and infrastructure behind your release. Then launch an Ares mission against the environment you just deployed, evaluate findings against your release policy, and give developers the evidence behind the result.
RELEASE EVIDENCE
Repository review and runtime missions give your release policy evidence to act on.
THE ARES METHOD
Connect the repository. Choose the review. Follow the evidence.
02
Select Source Code or Infrastructure. Both use the same repository connection; each is a separate campaign.
03
Review one commit on one branch. Ares reads the current tree, not repository history; no intensity setting is needed.
04
Ares takes a shallow clone, reviews the files and their relationships, then deletes the clone. Nothing is written back.
05
Schedule recurring reviews or call them from your build pipeline so the review follows what is about to merge.
One repository connection. Separate review lanes. Evidence for your release.
DEPLOYED-ENVIRONMENT MISSIONS
Unit tests confirm expected behavior. Build checks confirm that the software compiles. An adversarial assessment asks a different question: can someone use the running application in a way your team did not intend?
Ares brings that question into the release workflow. Assess reachable application and API behavior, investigate security exposures, and return a decision your pipeline can act on.
Give teams a repeatable way to test the deployed system before promoting it to production.
MISSION WORKFLOW
Register the target, authorize the environment, and create a pipeline credential. Choose a reusable mission profile or start with the target directly.
Add the action, container, template, or generated workflow. Store the API key in your CI secret store.
After the environment is deployed and reachable, start the mission. Supply the preview URL and release context where applicable.
Ares runs the assessment and evaluates the completed result against the captured gate policy. The pipeline receives the verdict and the reason behind it.
Use your pipeline’s configured conditions to continue or hold promotion. Investigate findings in Ares, remediate, and run the mission again.
CONFIGURABLE QUALITY GATES
Gate on severity counts or the total. Choose outstanding findings or every finding surfaced by the mission.
Critical findings greater than zero
Fail the gate if the mission surfaces a counted critical finding
High findings greater than zero
Fail the gate if the mission surfaces a counted high finding
Critical greater than zero OR high greater than two
Fail when either threshold is crossed
No gate rules configured
Report findings without enforcing a findings-based gate
Start in reporting mode, then enforce thresholds your team is prepared to act on. Gate rules are captured when the mission launches; editing a profile does not replace the policy already assigned to an in-flight mission.
The gate counts findings surfaced by the current mission, not a commit-to-commit vulnerability delta. A recurring unresolved exposure can count again.
RESULTS THAT NEED DIFFERENT RESPONSES
A failed quality gate and an assessment that could not be completed need different responses.
Gate passed
The completed assessment did not cross its configured thresholds
Gate failed
Counted findings crossed one or more rules
No gate configured
Results are reported; no findings-based policy was applied
Inconclusive or execution error
The assessment could not provide a usable gate decision
Continue or hold promotion according to your workflow’s configured conditions.
Investigate the counted findings and linked assessment evidence.
Resolve credentials, authorization, cancellation, or the client wait budget.
A passed gate is not a guarantee that the application has no vulnerabilities. No-wait does not enforce a verdict, and a client timeout does not automatically cancel a mission.
INTEGRATION PATHS
GitHub Actions
Published Ares action with job summaries and structured outputs
GitLab CI
Container-based integration
Azure DevOps
Pipeline template
Jenkins, CircleCI, Bitbucket, and other compatible runners
Container or CLI workflow
Teams using direct API calls
CI run endpoints for launching missions and retrieving results
The setup flow generates configuration for supported platforms. A standalone workflow option supports teams that need directly inspectable scripts. Your runner needs access to Ares; assessment infrastructure needs an authorized route to the target.
MISSION PLACEMENT
Deploy to staging, run the configured mission, and make the Ares result part of the pipeline condition for promotion.
Pass the environment’s URL into the mission so the assessment reaches that deployed build. Use a trusted workflow with the required credentials and domain authorization.
Trigger an assessment after a successful deployment to evaluate the running application. A finding at this stage informs your response; it does not automatically reverse the deployment.
Run deeper assessments outside the critical release path. Use pipeline schedules or recurring campaigns to revisit exposures without making every build wait for the most extensive mission.
TRACEABILITY
Record the supplied commit, branch or reference, repository, and pipeline URL alongside the mission. Keep the assessed URL visible, including when it differs from the target’s usual address.
In GitHub Actions, job summaries expose the gate result and severity counts. Structured outputs let subsequent workflow steps use the verdict, run ID, assessment link, and counts without parsing a log.
The full assessment gives security and engineering teams a shared place to review findings and supporting evidence.
OPERATIONAL BOUNDARIES
TALK TO ASSAIL
Discuss pipeline missions, authorized preview environments, and release policies your team can operate.
Your environment. Your objectives. A mission built around both.
