Project Security Scanning

The Security section allows you to run automated security assessments against your project repository. It analyzes your codebase inside an isolated execution environment and produces structured reports that identify vulnerabilities, misconfigurations, and risk patterns.

Security scans are project-scoped and operate only on the connected repository within the sandbox.

Running a Security Assessment

To begin a scan:

1. Open the project.
2. Navigate to Security.
3. Click Start Assessment.

If no scans have been executed yet, the Findings view will show:

No findings Run a security assessment to discover vulnerabilities.

Once started, the scan runs inside an isolated container. The system analyzes the repository and generates a report when complete.

Findings

The Findings tab displays the latest security results.

If vulnerabilities are detected, they will appear here with structured classification. If no issues are found, the report will indicate a clean result with a score.

Example outcome:

• Status: Clean
• Score: 100 / 100
• Result: No vulnerabilities found

This provides a quick executive-level signal about the project’s current security posture.

Scan History

The History tab maintains a log of all past assessments.

For each scan, you can see:

• Date
• Number of findings
• Files analyzed
• Duration
• Execution status (e.g., executing, completed)

This allows teams to:

• Track security posture over time
• Verify that scans were executed before releases
• Maintain an audit trail of security checks

Each scan entry can be opened to review its full report.

Report Structure

Each completed assessment generates a structured report with multiple sections:

Executive Summary

Provides a high-level overview including:

• Overall status (e.g., Clean)
• Security score
• Summary of findings
• Scan identifier
• Confirmation that the assessment was performed inside an isolated container

This section is designed for engineering leads and decision-makers who need a fast security signal.

Full Report

The full report contains detailed findings, including:

• Identified vulnerabilities
• Affected files
• Risk classification
• Technical explanations
• Suggested remediation guidance

This section is intended for developers implementing fixes.

Compliance

The Compliance tab summarizes alignment with security and operational best practices. This can be used to:

• Validate internal security policies
• Prepare for audits
• Demonstrate secure development workflows

Deliverables

Reports can be exported in structured formats such as JSON.

This allows integration with:

• Internal compliance systems
• External audit workflows
• Security dashboards
• CI/CD validation pipelines

How Security Analysis Works

Security scans execute inside an isolated container environment. The assessment:

• Reads the full repository
• Evaluates configuration files
• Analyzes dependency usage
• Inspects application logic for common vulnerability patterns
• Detects misconfigurations and insecure patterns

All analysis is contained within the project boundary. The scanner does not access external systems unless explicitly configured.

When to Run a Scan

Security assessments are recommended:

• Before merging major features
• Before release
• After dependency upgrades
• After infrastructure changes
• During periodic security reviews

Because scan history is retained, teams can demonstrate consistent security validation over time.

Isolation and Safety

Security scans:

• Run inside sandboxed containers
• Do not modify the repository
• Do not push changes
• Do not affect active development sessions

They are read-only assessments focused solely on identifying risk.

Using Security in Practice

A typical workflow may look like:

1. Implement feature changes in a Chat Trial.
2. Run tests and validate behavior.
3. Open Security → Start Assessment.
4. Review the Executive Summary.
5. Inspect detailed findings if any issues are reported.
6. Fix vulnerabilities in a new trial.
7. Re-run the scan to confirm resolution.
8. Create a pull request once the project is clean.

This ensures that security validation becomes a natural part of the development lifecycle rather than a separate, external process.