AI Code Security and Supply Chain in Romania

Checkpoints from commit to server

The chain has four checkpoints. In the code, SAST with Semgrep rules looks at input validation, queries built by concatenation and missing authorisation on routes. In dependencies, an SBOM is generated on every build and compared with vulnerability databases. In images, layers are scanned, a non-root user is required and cosign signs the result. In infrastructure as code, checkov rules catch public storage, open ports and over-wide permissions. Secret scanning runs everywhere, including the repository history.

• SAST on every pull request, with rules adapted to the project
• gitleaks on commits and on history, with rotation of found keys
• SBOM with Syft, verified with Grype on every build
• Images signed with cosign and verified at deploy time
• checkov on Terraform, Ansible and Kubernetes manifests

What goes wrong in code written with AI assistants

Models produce code that compiles and looks right but repeats unsafe habits from their training data: string concatenation in queries, missing validation, poor cryptographic choices, secrets typed straight into a file, and invented package names that someone else later registers. The real issue is speed: more code per hour means more attack surface. The same models also help defend: triaging SAST results, explaining a finding in the context of its function and proposing a fix. The checks stay deterministic, and the merge decision stays with a person.

Gates that do not slow the team

A gate that blocks everything is switched off within two weeks, so we calibrate it: fail only on high severity and on secrets, warn on the rest, and keep a list of exceptions with an owner and an expiry date. Scans run in parallel with the tests, so build time does not grow noticeably, and vulnerability databases are cached. On a pull request we comment only on what is new compared with the base branch, so the developer sees what they introduced rather than the project's historical debt.

Where the pipeline runs and what we maintain

We configure the pipeline on GitHub Actions, GitLab CI or a self-hosted runner on your VPS in Frankfurt, if you want the source to stay inside your own infrastructure. You request the work from the DevOps Services section of the client panel. From the monthly hours (1 h on cPanel from Advanced up, 1–8 h on VPS, 5–10 h on dedicated by plan, 10 h on GPU) we keep rules current, review expired exceptions and add checks to new projects. A large pipeline refactor exceeds the allowance and is billed separately. Hours do not carry over.

How we work

1. Request from the panel

   Ask for pipeline hardening in DevOps Services: tell us where the code lives, how you deploy and which thresholds you can accept at the start.

2. Repository assessment

   We run a first pass: SAST, secrets in history, dependencies, images and IaC. You see what a gate would block today and what can be fixed quickly.

3. Implementing the gates

   We add the steps to CI, calibrate severities, rotate exposed keys and sign images. Gates move gradually from warning to blocking.

4. Handover and maintenance

   You receive the configuration, the exception list with expiry dates and the documentation. We review the rules regularly from the included hours.

Use cases

Technology stack

• Semgrep
• gitleaks
• Syft
• Grype
• Trivy
• checkov
• cosign
• Dependency-Track
• pre-commit

Frequently asked questions

• Is AI-generated code secure?

  Not by default. It compiles and looks fine, but it repeats unsafe patterns: missing validation, queries built by concatenation, secrets in files, packages that do not exist. Treat it like code from a new colleague: useful and fast, but put through the same automated checks and a human review.

• What is vibe coding and what are its security risks?

  The term for building an application by chatting with a model without reading closely what comes out. The risk is not syntax but what you cannot see: absent authorisation, exposed data, unknown dependencies. A gate in CI turns the gamble into a repeatable process.

• What is slopsquatting?

  An attack on package names that a model invents. An assistant suggests a library that does not exist, someone registers that name with malicious code, and the next developer to follow the suggestion installs it. We verify names and provenance during the build and block untested automatic updates.

• What is an SBOM and do I need one?

  The full list of components your software is built from: libraries, versions and licences. We generate it on every build with Syft and check it with Grype, so when a new CVE appears you know within minutes whether it affects you, and in which delivered version.

• SAST or DAST: which one and when?

  SAST reads the source and catches classes of flaws before deployment, on every pull request. DAST attacks the running application and catches what only appears at runtime: configuration, sessions, integrations. We use both, SAST in CI and DAST on the test environment before a release.

• How do I keep API keys out of my repository?

  Scan at commit with pre-commit and gitleaks, plus one pass over the whole history, because an old secret stays valid. Found keys are rotated, not merely deleted from the code. Secrets live in environment variables, in SOPS or in a vault, never in versioned files.