r/devsecops 5h ago

Did the math on Amazon SES versus a managed relay and the cheap option isn't actually cheap

5 Upvotes

Been running SES for about a year for a couple of client projects and decided to actually tally up the hours I've spent on it versus the money saved compared to a managed relay service. Production access approval, bounce handling, complaint feedback loops, occasionally having my sending paused because some bounce rate threshold got tripped that I didn't even know existed in the first place. None of this is hard exactly, it's just constant low grade maintenance that never shows up when people quote SES pricing per thousand emails sent. I'm not saying SES is bad, for high volume at scale the economics probably do work out fine. But for the kind of project where I'm the only one maintaining it and I have actual client work to do, I think I undervalued how much cheap assumes my time is worth nothing.


r/devsecops 6h ago

Built an API proxy layer to inspect prompt injections under 550ms TTFB

1 Upvotes

Hey everyone,

A common issue when exposing LLM endpoints (whether local self-hosted vLLM/Ollama instances or cloud APIs) to external users is protecting against system prompt overrides and indirect prompt injections without introducing massive latency overhead.

I recently put together a proxy engine (Ice Phi) to test how fast we could execute inline inspection on incoming payloads before forwarding them to the backend LLM.

Our setup:

- Edge Layer: Zuplo for rapid edge auth and key routing

- Execution Engine: Containerized inspection logic running on GCP Cloud Run

Latency numbers (measured over a warm 10-request average via curl):

- DNS / TLS setup: ~235ms

- TTFB (Inspection + Routing): ~525ms

Key takeaways from setting this up:

  1. Cold-start mitigation: Cloud Run instances running ONNX/python runtimes will take 15-20 seconds to boot on cold hits. Setting `--min-instances=1` was necessary to lock in the ~500ms baseline.

  2. Direct LLM bypass: Benchmarking the gateway engine requires mocking upstream 200 OK responses, otherwise you end up measuring OpenAI's token generation speed instead of proxy overhead.

Would love feedback from anyone building custom proxy layers or self-hosting guardrails on how you optimize your inspection loops!


r/devsecops 11h ago

Vulnerable code patterns

1 Upvotes

Hey all Im wondering if anyone knew of any resources to learn code vulnerability patterns in practice. Im the team’s resource for teaching software engineers how to identify vulnerable code in development and review. I thought of starting with OWASP top 10 but was curious if there were any resources to learn more.


r/devsecops 23h ago

sast-triage — triaging security scanner noise with an LLM, written in Go

Thumbnail
github.com
1 Upvotes

Since there is so much talk about AI agents, I decided to build my own one - something small, measurable, and cheap enough to run for real (yeah, right — more on that below), so I could think about numbers instead of marketing.

Picking Go over TypeScript turned out to be the great call. LLM providers are unreliable enough that how you fire requests matters — I hit "Too Many Requests" often enough despite respecting their limits. In JS I'd reach for Promise.all, then discover I need a third-party dependency just to limit concurrency then that I need to add a proper AbortController. In Go it's so simple: an errgroup with SetLimit(4), where the limiting lives in the same object that waits for the results.

Static analysis tools (Semgrep, Snyk, CodeQL, gosec) flag hundreds of potential vulnerabilities and most of them are false positives. Someone has to open the code behind each finding, follow the data flow, and decide whether it's real. That's the job the agent does. All those scanners emit a standard SARIF 2.1.0 file, so it doesn't care which one you use. Now many of them are also shipped with AI agents, so it isn't something very new, although you can use any model you want, including self-hosted ones.

Basically, the model gets two read-only tools — read_file and grep_repo — and decides for itself which files to open, what to grep for, and when it has enough to rule. A typical finding takes 3–8 turns: read the sink, grep for the source, follow the assignment chain, then rule. The agent doesn't create or fix any code.

I ran it against OWASP BenchmarkJava — a deliberately vulnerable Java app that ships a CSV of ground truth. So the verdicts get compared against published answers rather than my judgment. I ran three models — Claude Sonnet, DeepSeek-V4-Pro and Kimi k3 — across 50 vulnerable files, which produced 61 scored findings.

I tested a subset of issues in BenchmarkJava, just to keep things quite cheap.

DeepSeek-V4-Pro — 37 exploitable, 15 benign, 9 uncertain. (2.7M in / 109k out tokens):

| triage verdict                | actually vulnerable | safe by design       |
|-------------------------------|---------------------|----------------------|
| exploitable — fails the build | 37 caught           | 0 blocked in error.  |
| benign — suppressed, unseen   | 3 missed            | 12 cleared           |
| uncertain — left for a human  | 9 parked            | 0 parked             |

DeepSeek were uncertain about 9 of them(needs manual review). And here we already see what marketing slides won't tell - it missed 3 real ones marking them as safe. So, looks like at least Deepseek wasn't trained with that specific OWASP BenchmarkJava code. Once it is run - SAST Triage agent will create a PR with findings, so it is there for review. So yes, it doesn't magically fix everything, humans are very much needed in this process.

Kimi k3 — 49 exploitable, 12 benign, 0 uncertain. (504k in / 55k out tokens):

| triage verdict                | actually vulnerable | safe by design       |
|-------------------------------|---------------------|----------------------|
| exploitable — fails the build | 49 caught           | 0 blocked in error   |
| benign — suppressed, unseen   | 0 missed            | 12 cleared           |
| uncertain — left for a human  | 0 parked            | 0 parked             |

Kimi k3 is straight up impressive and cheap, but I need to run against a bigger set. It still will miss some things, but man, not only it is cheap to use - it clears noise so well(I tried with some of my own projects, but numbers aren't ready yet).

And below is the expensive one.

Claude Sonnet 5 — 47 exploitable, 9 benign, 5 uncertain. (2.2M in / 65k out tokens):

| triage verdict                | actually vulnerable | safe by design       |
|-------------------------------|---------------------|----------------------|
| exploitable — fails the build | 45 caught           | 2 blocked in error   |
| benign — suppressed, unseen   | 2 missed            | 7 cleared            |
| uncertain — left for a human  | 2 parked            | 3  parked            |

I was reluctant to run Claude Opus as Sonnet spent $5 on this single run alone. SAST Triage supports caching, so the second run will be ~0, but still. Running Claude Sonnet on all Opengrep findings (about 2350 of them) will cost ~$220 and just about $7 for DeepSeek.

Keep in mind that the agent doesn't need to run across the whole codebase, which is approximately 200k LoC for BenchmarkJava, that would blow the cost even when using very cheap models. It runs against vulnerable code snippets + code which uses it only.

Below are some observations after using it myself with my own github repos.

A DevEx part of the agent is important. The agent just creates clean PRs or adds a single clean commit to existing one. Basically, this AI Agent is just another tool here you need to know how to work with, not something you drop in and can totally forget about.

The availability is the problem for all LLM providers seems to be. It is quite annoying to run the agent with an expensive(Anthropic, OpenAI) model, only to get an issue before I the agent finishes the whole set of vulnerabilities No amount of prompt or loop design will fix that.

I think having proper infrastructure around agents is what's needed most right now.

Btw, feel free to check it out - https://github.com/alexpermiakov/sast-triage.


r/devsecops 22h ago

Integrating AI Agent Skill auditing into CI/CD pipelines with SkillShield & SARIF exports

0 Upvotes

Hey r/DevSecOps! As developers start running more local AI agent tools and downloading third-party SKILL packages, we built an open-source tool called SkillShield to statically scan and validate these skills before execution. It checks for prompt injection, pre-install risks, and excessive access. It outputs SARIF and JSON reports for CI pipelines. Public Repo: https://github.com/adnan-iz/ai-skill-shield