What is code security?

Code security at a glance

What code security covers

Most of what runs in production was not written by your team. A typical service is your code, a large tree of open-source packages, a base image, Terraform or CloudFormation that creates the cloud resources, Helm charts or manifests that deploy it, and a pipeline that holds the credentials to do all of that. Each layer can carry a defect, and each needs a different technique to find it.

SAST vs SCA vs IaC scanning

DAST — dynamic application security testing — is the fourth technique. It exercises the running application from outside, so it finds what is genuinely reachable, including configuration and deployment problems no static tool sees, but only on paths it manages to reach.

Secret detection cuts across all of them: credentials in source, in commit history, in image layers, in pipeline variables and in committed state files. Tools such as Gitleaks and TruffleHog run as pre-commit hooks and in CI. See What is cloud secrets management?.

SBOM — a software bill of materials, in SPDX or CycloneDX format — is the inventory SCA produces. Keep one per build, so "which running services contain this package?" is a query rather than a project.

What is IaC scanning?

IaC scanning evaluates infrastructure-as-code against security policy before anything is created. It is the earliest point to catch a cloud misconfiguration: the template that will create a public bucket, rather than the public bucket.

Scan in two places. The template in the pull request catches the mistake when it is cheap to fix. The plan (terraform plan output) catches what the template resolves to once variables and modules are filled in — a module default can open a port that the template never mentions.

What is security as code?

Security as code means writing security policies, controls and tests as versioned code that runs automatically, instead of as documents and manual reviews. Examples: an OPA or Kyverno policy that rejects privileged pods; a Checkov custom rule that blocks unencrypted databases; a pipeline step that fails on a leaked credential.

The difference from code security is direction. Code security scans code for defects. Security as code turns security rules themselves into code — reviewed in pull requests, tested, and enforced by the pipeline. Mature teams do both: the scanners are the checks, and security as code is how the policy those checks enforce is written down and versioned.

Why fixing it in the console makes it come back

A posture tool reports a storage bucket with public access. An engineer opens the cloud console, unchecks the box and marks the finding resolved. The next terraform apply recreates the bucket exactly as the template describes it — public — because the template was never changed.

The finding returns, gets re-triaged, gets fixed in the console again. Everyone is working; nothing is improving.

The fix has to land where the resource is defined. That means knowing which template, repository and line produced a given running resource — connecting the code side to the runtime side rather than running two programmes that never meet.

Code security examples: three findings and their fixes

1. IaC — a bucket created without a public-access block. The scanner flags the template in the pull request. Fix in the template, not the console:

resource "aws_s3_bucket_public_access_block" "exports" {
  bucket                  = aws_s3_bucket.exports.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

2. SAST — SQL built from user input. The analyser traces a request parameter into a query string. Fix: use a parameterised query.

# Before: cursor.execute(f"SELECT * FROM orders WHERE id = {order_id}")
cursor.execute("SELECT * FROM orders WHERE id = %s", (order_id,))

3. Secret detection — a cloud access key in a config file. Deleting the line is not enough; the key is in commit history. Fix: revoke and rotate the key first, then remove it from history, then move the value to a secrets manager and block the pattern with a pre-commit hook.

Reachability is what makes the numbers usable

A dependency scan on a mature service can return hundreds of findings. Fixing them in CVSS order sounds reasonable and wastes most of the effort, because severity describes the vulnerability, not your exposure to it. Three questions change the order:

1. Is the vulnerable function called? A critical CVE in a code path the application never executes is not a critical risk to that application.
2. Is the workload reachable? The same container behind an internal service and behind an internet-facing load balancer carries very different risk.
3. What can it reach next? A vulnerable workload with a read-only role is contained. The same workload with a role that can assume other roles is an entry point — see attack path analysis and CIEM.

None of those can be answered from the code alone, which is why code findings become useful when they are joined to runtime and cloud context.

Where code security belongs in the pipeline

The rule that keeps this survivable: gate on the delta, not the backlog. A pipeline that fails on every pre-existing finding gets switched off. One that fails only on newly introduced findings holds the line while the backlog is worked separately.

Code security best practices

1. Detect secrets before code leaves the laptop, not after it reaches the default branch.
2. Prioritise SCA by reachability, not by CVSS alone.
3. Scan IaC against the plan, so misconfigurations are prevented rather than reported.
4. Fix at source. Every runtime finding should trace back to the template and repository that produced it.
5. Write policy as code. Version it, review it and test it like any other code.
6. Protect the pipeline itself. Branch protection, least-privilege CI tokens and short-lived cloud credentials through OIDC — the pipeline holds the keys to production.
7. Keep one inventory across code and cloud, so a new CVE can be traced to running workloads in one query.

How Onam approaches code security

Onam's cleared figures in this area cover the platforms code lives on and the cloud it deploys to. GitHub and GitLab are two of its eight SaaS posture connectors, with 122 CIS rules for GitLab; in its cloud rule catalog, 502 rule definitions are tagged to secrets and key management and 241 to application and API. One honest limit: GitHub has posture checks but no CIS rule pack yet.

• Onam Code Security
• Onam SaaS Security (GitHub, GitLab)