SecOps — Code & Application Security

Onam SecOps brings SAST, DAST, and SCA/SBOM scanning into the same platform as your cloud posture data — correlating code vulnerabilities with cloud exposure context to surface the risks that truly matter. A SQL injection in an internet-exposed function with broad IAM permissions is not the same risk as the identical bug in an internal batch job; SecOps scores them accordingly.

This page covers the three scan types, SBOM generation, the AI-powered fix engine, and CI/CD integration.

SAST — static application security testing

The SAST engine analyzes source code across 7 languages using dedicated per-language scanners plus a Semgrep-based rule engine with curated rule packs:

A dedicated Kubernetes manifest scanner covers workload definitions alongside application code. Rule content draws on the OWASP Top 10, CWE Top 25, and cloud-specific security patterns, and custom rules are authored in Semgrep-compatible YAML — version-controlled alongside your repository content.

DAST — dynamic application security testing

The DAST scanner exercises running applications with active test payloads across 12 vulnerability classes:

• SQL injection (MySQL, PostgreSQL, MSSQL, Oracle, SQLite variants)
• Cross-site scripting (reflected, stored, DOM-based)
• Server-side request forgery (internal network, cloud metadata endpoints)
• XML external entity injection
• Template injection (Jinja2, Twig, Freemarker, Pebble, Velocity)
• IDOR / broken object-level authorization
• Authentication bypass (default credentials, forced browsing, JWT attacks)
• Business logic flaws (price manipulation, quantity bypass)
• HTTP request smuggling
• GraphQL introspection and injection
• API security (broken authentication, excessive data exposure, mass assignment)
• File upload bypass

Point DAST only at environments you own and are authorized to test. Payloads are active — they exercise real injection and authentication paths. Staging environments with production-like configuration give the best signal.

SCA — software composition analysis

SCA scans third-party dependencies across the major package managers — npm/yarn/pnpm, pip/poetry, Maven/Gradle, Go modules, Cargo, Bundler, Composer, and NuGet — and builds the full transitive dependency tree, not just direct dependencies. CVEs are flagged at the level where they are introduced and attributed back to the direct dependency that brought them in.

Every component is enriched from the same intelligence feeds the Vulnerability engine uses:

SBOM generation

The SBOM engine generates a complete Software Bill of Materials from a Git repository URL — it clones the repo, reads every dependency file directly from source, and builds the component inventory. No external tooling required.

• Output is CycloneDX 1.5, the OWASP standard format required by US Executive Order 14028 for federal software contracts
• Full component inventory: name, version, package URL, licenses, checksums
• CVE status pre-populated for every component, with EPSS and KEV data embedded
• VEX support — record "this CVE exists in our dependency but we are not affected because..." with a documented reason, so known-safe findings stay silenced with an audit trail
• Accepts pre-built CycloneDX or SPDX files as an alternative input path
• Exportable as JSON or XML for procurement, regulatory, and audit purposes

AI-powered fixes

For SAST findings, the platform's Remediation engine generates a source-code fix — not just a description of the problem:

1. Context injection — the engine receives the vulnerable snippet, the surrounding file context, the finding description, and the cloud context: is this code running in an internet-exposed function, and what IAM permissions does it hold?
2. Fix generation — a corrected code diff is produced that addresses both the code vulnerability and any amplifying cloud context.
3. Confidence scoring — each fix is rated High, Medium, or Low confidence based on similarity to known-good fix patterns.
4. PR integration — fixes can be applied directly as pull request suggestions in GitHub, GitLab, and Bitbucket.

CI/CD integration

SecOps runs as a CI/CD check, so vulnerable code and dependencies are blocked before they ship:

- uses: onam-security/secops-scan@v2
  with:
    api_key: ${{ secrets.ONAM_API_KEY }}
    fail_on: critical    # critical | high | medium
    exclude_accepted: true

Blocking gates are configurable per environment:

• Block any deployment to production with a Critical SAST finding
• Block any dependency with a KEV-flagged CVE from reaching staging
• Warn (non-blocking) on Medium findings in development branches

For infrastructure templates — Terraform, CloudFormation, Helm charts, Kubernetes manifests, ARM/Bicep, Pulumi, and Docker Compose — see IaC Scanning, which runs in the same CI/CD flow.

FAQ

How does SCA handle transitive dependencies? The full dependency tree is resolved to any depth. A CVE in a transitive dependency is flagged where it is introduced and attributed to the direct dependency that pulled it in, so you know exactly what to upgrade.

What is the difference between SecOps scanning and the CSPM engine? CSPM scans deployed cloud resources through read-only cloud APIs. SecOps scans source code, running applications, and dependencies before and after deployment. Running both gives you pre-deploy prevention and post-deploy verification.

Can I write custom SAST rules? Yes. Custom rules use Semgrep-compatible YAML, apply to any supported language, and are version-controlled alongside your repository content.

Next steps

• IaC Scanning — catch misconfigurations in templates before deployment
• Vulnerability Management — the shared CVE, EPSS, and KEV intelligence pipeline
• Container Security — image scanning and Kubernetes posture
• Book a demo — see a repository scanned end to end