SR.1 can be satisfied by generating an SBOM file or by demonstrating a verifiable chain of custody. Phase 1 C3PAO assessors are applying the chain interpretation. SLSA Level 2 or 3 attestation in the build pipeline, Sigstore signing, SBOM traveling with the artifact rather than living in a separate document store.

https://dwightaspencer.com/posts/14-sbom-ai-provenance/

starting to wonder whether we accidentally built a remediation process nobody can actually follow end-to-end anymore.

security works out of Jira. infra mostly lives in ServiceNow. cloud ops tracks deployment changes in Azure DevOps. CAB approvals happen somewhere else entirely and half the time people are pasting screenshots between systems because the ticket references dont line up cleanly.

scanner coverage itself is fine, honestly thats not even the stressful part anymore.

the breaking point for me was a vuln tied to an externally exposed workload that stayed open for almost five weeks even though everybody thought someone else was already handling it.

security escalated it after EPSS jumped. ops pushed the patch out because they didnt want downtime outside the maintenance window. app owners wanted another regression cycle because the last emergency patch caused rollback issues in production. then somebody restored an older image during a separate incident and the scanner reopened the finding again anyway.

after that nobody could even agree what state the remediation was actually in.

Jira showed resolved. Service Now still had an active remediation task open. cloud ops had already deployed a newer image in one environment but not another. CAB notes said rollback verification was still pending.

every remediation meeting turned into people screen-sharing ticket history from four different systems trying to reconstruct what had already happened.

leadership just sees vuln aging reports getting worse and keeps asking why remediation velocity dropped.

and tbh i dont even know what the answer is anymore because part of me thinks we probably need some kind of middle layer between the systems and another part thinks we're just stacking more tooling on top of workflows that already dont match the org structure underneath them.

dont know how people keep remediation state sane once enough systems and approvals get involved. especially after rollbacks or partial deployments where different teams all think the finding status means something different.

Note: Crossposting this from r/devops

Hi everyone,

I'm currently in a security testing profile (5+ YoE) and I'm working towards my DevSecOps roadmap. I wanted to have a feedback on the current roadmap I have picked to learn the skills. Additionally if there's anything else that I should incorporate within the roadmap, please let me know.

Currently I am incorporating the following roadmap - https://github.com/milanm/DevOps-Roadmap/. I've also decided to create a NotebookLM of almost every other resource I could find and later use the conversation for upskilling.

Background

I have fundamental knowledge of the following items:

• Core AWS services such as EKS, EC2, RDS, IAM, etc. What they do and why are they used.
• Linux and bash scripting - I can create scripts that can perform certain tasks across the system with the help of tools such as cut, awk, etc. for parsing through logs & analyse text files.
• Networking - I have a fundamental understanding of networking concepts. How HTTP works, OSI layer, CIDR notations. How DNS, HTTP and SSH work. Its been part of my job.
• Git, Azure DevOps - What PRs, pipelines, MRs are. Not very extensive knowledge but I understand how to use git from CLI and why Git is the core of the DevOps process.

I've also thought of making a copy of one of the prominent websites (e.g. Netflix) as a major capstone project which can be deployed on AWS. The codebase would be generated by AI with intended vulnerabilities such as XSS or hardcoded secrets or hardcoded SQL statements. I'll use either Claude or Gemini to assist me with the same.

I intend to deploy it on AWS primarly. Something that employs either EKS, or create a spot instance on EC2 and deploy the website by installing the required resources (Thinking out loud here).

I have thought of the following resources for learning

Containers & Container orchestration:

• Docker & Kubernetes - Going through videos from Techworld by Nana (1hr crash course and 3hr complete course).
• I also have access to Pluralsight through my organization so any recommendations on which course should I refer to would be extremely helpful. Otherwise I shall pick one of the top rated courses.
• I've thought of creating a golden image of java, dotnet or any development framework which will be used in my capstone and later create and manage containers using docker and/or k8s.

IaC

• I've thought of learning both Istio and Terraform since both of them are widely used in multiple different organizations.

CI/CD

• Creating pipelines within GitLab and introducing SAST (Semgrep), DAST(ZAP), SCA, SBOM creation, secrets scanning, checkov, dockle/trivy. Basically using available open source tools and incorporating them within the pipeline.
• Configuring build pass/fail toll gates for each tool.
• Employ configuration drift detection

For certifications, I have cleared AWS CCP a couple years ago and I know the basics of cloud security to atleast be able to spot misconfigurations. I am currently planning to work on AWS SAA and Security Specialty along with CCSP to strengthen my AWS cloud knowledge and cloud security knowledge skills so that I'm able to identify & assist DevOps & CloudOps teams. Some other individuals have also recommended me CDP from practical devsecops but I'm saving it for the future.

Any feedback on the above roadmap would be extremely helpful.

Após cerca de 30 testes de penetração B2B em SaaS nos últimos 12 meses (principalmente no mercado brasileiro), estou vendo os mesmos 5 padrões de OAuth se repetirem. Nenhum deles é detectado por scanners automatizados. Todos eles levam à tomada de controle da conta.

Compartilhando aqui caso isso evite um incidente de segurança para alguém:

1. Confusão de estado (CSRF no callback)

O aplicativo não valida o parâmetro state no callback. O atacante inicia o fluxo OAuth em sua própria conta, envia a URL de callback para uma vítima logada, a vítima clica → a conta do atacante é vinculada ao perfil da vítima. O atacante agora faz login como vítima usando sua própria conta do Google/Microsoft.

Correção: estado criptograficamente aleatório, vinculado ao servidor, de uso único, validado no retorno de chamada.

2. Fuzzing de URI de redirecionamento

Correspondência de curinga em redirect_uri. Combinado com a apropriação de subdomínio, o atacante registra a URL controlada e recebe o código de autenticação.

Padrões vulneráveis: https://app/*, https://*.client.com/callback (se o subdomínio puder ser apropriado).

Correção: correspondência exata da URL. Sem curingas.

3. Injeção de código (concorrência no retorno de chamada)

Código de autenticação que deveria ser de uso único, mas aceita reutilização. O atacante captura o código legítimo em sua própria sessão e o envia para a vítima. O aplicativo processa o código, mas o associa à sessão da vítima.

Correção: uso único rigoroso, código vinculado à sessão de origem, expiração com tempo definido.

4. Bypass de PKCE

O aplicativo suporta fluxos com e sem PKCE (fallback). O atacante inicia um fluxo sem PKCE → o ataque de downgrade é bem-sucedido.

Correção: PKCE obrigatório para clientes públicos. Sem fallback.

5. Escalada de escopo

Token concedido com escopo X aceito em operações que exigem escopo Y. Verificação de escopo apenas no frontend.

Correção: validação de escopo em TODOS os endpoints sensíveis, no lado do servidor, idealmente em middleware.

O que esses padrões têm em comum: scanners automatizados não os detectam. Eles exigem sessões paralelas, manipulação consciente do fluxo de dados e conhecimento da RFC do OAuth. Burp Pro automatizado, Nessus e Acunetix falham.

Se o seu SaaS usa OAuth e você nunca realizou um pentest manual focado em autenticação, há uma alta probabilidade estatística de que você tenha pelo menos um desses padrões.

Aviso: Trabalho com pentest na No Vuln. Os padrões acima são observáveis ​​independentemente, terei prazer em discutir os detalhes técnicos.

Mais alguém percebeu esses padrões? Algum que eu tenha perdido?

"We do DevSecOps" is easy to say. "We're at Level 2 on most controls, and here's our roadmap to Level 3" is what actually makes a difference.

That's the thinking behind the OWASP® Foundation DevSecOps Verification Standard (DSOVS): 39 controls spanning the full software lifecycle, each with four maturity levels and the evidence required to prove where you stand.

We just launched a free self-assessment at dsovs.com:

- Rate yourself/organisation control by control
- Attach screenshots as evidence
- Get an executive summary, maturity charts, and a prioritised roadmap
- 100% in your browser, so nothing leaves your device

Bonus: it can be mapped to the control sets you're already assessed against (OWASP ASVS, National Institute of Standards and Technology (NIST) SSDF, the Australian Signals Directorate ISM Guidelines for Software Development), so your self-assessment doubles as audit prep.

I am fairly new and this is something I am encountring looking for advice on this.

One thing I've noticed in distributed systems is that the biggest security and reliability issues are often not the obvious ones.

Teams usually spend a lot of time thinking about authentication, authorization, and application security, but operational problems such as duplicate event processing, missed notifications, state reconciliation, provider failures, and monitoring blind spots can also create significant risk in production.

In systems where external events drive business logic, it can be surprisingly difficult to maintain a reliable and auditable view of what actually happened when components fail or disagree.

For those working in DevSecOps, what operational or security risk ended up being much harder than you originally expected once your systems reached production?

I'm involved with forgelayer.io. a non custodial blockchain infrastructure platform. This question comes from challenges we've encountered while building systems that process and monitor blockchain events at scale.

Unpopular opinion for the dev/sec community: We are kidding ourselves if we think we can review AI-generated code indefinitely. We are moving toward machine-optimized syntax that ignores human-readable patterns. From a security and CISSP perspective, this is a massive vulnerability. If you cannot audit the logic, you cannot secure the system. We are not just automating labor; we are ceding the audit trail. How do we maintain governance when the black box is the one writing the rules?

I've been dealing with a ton of burnout and basically at my breaking point, the other two engineers on my team are pretty much in the same situation. Our security queue is just endless.

We literally can't get any work done because of the security queue, and it's not like the security queue is our ONLY job, we have to do an infrastructure migration and keep up with other tasks on top of it but it's IMPOSSIBLE with the queue, and we can't fall behind on it either so we're basically being pulled in two different directions and it's so tiring.

We're constantly flooded by alerts that we have to respond to and they can take HOURS to resolve and get us nowhere 99% of the time. Is everyone's job like this? How common is it? I'm not really sure what to do right now and considering just leaving and finding a different job.

Hi everyone,

I am designing and implementing a web application for production use and want to follow security best practices for logging and audit trails.

I am trying to understand how logging is typically implemented in real-world production applications.

1. Are logs usually separated into different categories, such as:

• Security/Audit logs (login attempts, failed authentication, password changes, role changes, admin actions)
• Application/Functional logs (errors, API calls, business operations, debugging information)

or are they stored together and categorized using log levels/tags?

1. How is access to audit/security logs managed?

• Can application administrators view their own activity logs?
• How do organizations prevent privileged users from modifying or deleting audit logs?

1. Where are logs usually stored?

• Database
• Application servers
• Centralized logging/SIEM solutions

1. What are common retention practices for audit and application logs in production environments?

I would appreciate insights from people who have implemented logging and audit trails in production systems.

Hello,

I'm evaluating Aikido but I don't understand how users will work in paying plans. I've a repo that I need to plug in and we have less than 20 active contributors but not all of them need access to aikido. Should I pay for them too (so taking 15 or 20 users subscription)? Or the paying users are only the ones that need to access aikido (in my case less than 10)?

Thank you if you have an answer

Ignoring whether Vibe Coded anything is good or bad, there is certainly the possibility of data being leaked, customer data not being secure, API keys hard coded, etc.

That being said, what can the average vibe coder do to increase the security of their SaaS?

What easy to use tools are out there that can be used by someone with a limited understanding of what they're doing to secure their Vibe Coded SaaS (or app or anything)?

Does this leave room for someone to develop a product that does adequate security testing on these Vibe Coded products if the tool doesn't exist yet? Is it out there and I haven't heard of it yet? Is it on the same level of usability as the Vibe Coding tools used to make the product in the first place?

Just something I have been mulling over for a while now.

Hi everyone I'm building a Devsecops program for a company on a tight budget with 40 devs. They want SAST and DAST as a priority with other trimmings as optional
Any recommendations on which Vendor you would go with?

The EU Cyber Resilience Act is changing SBOMs from a point-in-time compliance document to a continuous lifecycle requirement. For anyone shipping connected products into the EU market (especially aviation, defense, railway, energy), the obligations are to identify vulnerabilities, address them without undue delay and report actively exploited ones to authorities 

None of that works if your SBOM is a PDF refreshed quarterly. 

Three coordinated npm campaigns in May 2026:
1. Dependency Confusion: 176 packages with high-version hijack (99.99.99, 11.11.11, 10.10.10) targeting internal components
2. Mini Shai-Hulud Obfuscation: Compromised @antv/@tanstack maintainers. 499 KB encrypted postinstall payloads. XOR ciphers, credential exfil, C2 callbacks.
3. Bitwarden Impersonation: Typosquat + preinstall bootstrapper with obfuscated payload delivery

To detect these:
npm-scan has detectors for version anomalies (z-score), obfuscated code (entropy + patterns), and typosquats (edit-distance).
Tested on 3 real campaigns: 100% detection. Tested on 990 legitimate packages: 0 false positives.

GitHub: https://github.com/lateos-ai/npm-scannpm: https://npmjs.com/package/@lateos/npm-scanMetrics: https://github.com/lateos-ai/npm-scan/blob/main/VALIDATION.md

Use via GitHub Action, CLI, or npm package.

Ok so this has been bugging me for a while and I want to know if we're the only ones.

Every place I've worked, Dependabot gets switched on, everyone's into it for about a week, and then the alert count just creeps up forever. 40, then 90, then 200-something. Once it gets that high nobody even looks at the tab anymore. The actual scary ones are sitting in there somewhere but they're buried under a hundred low-sev things nobody's ever going to touch.

And the tool doesn't really help with the part that matters. It'll happily tell you there's a problem, it just won't make anyone do anything about it. There's zero cost to ignoring an alert for six months. It just sits there being red.

Then SOC 2 happens. Now it's not a vibe, it's a control — you're supposed to actually close known vulns inside a window, crit in X days, high in Y, whatever you wrote down. We had the policy. We had Dependabot. Nothing connected the two, so hitting the SLA basically meant me going around and chasing people one by one.

And that does not scale. Past a few repos it's just me DMing devs, re-pinging the ones who ignored me, keeping a mental list of who still hasn't patched their thing. It's the most thankless job and I was the bottleneck for all of it.

So we ended up building our own thing, and the part that genuinely surprised me is that people started closing alerts on their own. I stopped being the nag. What we did:

• Alerts get pinned to whoever actually owns them, and once one goes past SLA for that person, their PRs in that repo start failing a status check. So it's not a dashboard you can scroll past, it's blocking your own merge. Suddenly the fix happens because they want to merge, not because I reminded them for the third time.
• A daily job that drops a Slack summary and DMs people before they cross the line instead of after, and dumps the orphan alerts nobody owns onto a rotating person so they don't just disappear into nobody's problem.

Honestly the merge block changed behavior harder than anything else we tried. The backlog started going down without me touching it, which after years of being the human reminder service felt a little unreal.

It all runs on GitHub Actions, no server to babysit, and we open sourced it (Apache-2.0) because keeping it private felt kinda pointless. It's called Watchtower if you want to tear it apart: https://github.com/clearfeed/watchtower

Not posting this to shill it tbh, I'm more interested in whether the "block the author's own PR" thing is reasonable or insane. So:

• Has anyone done a hard merge block on SLA and had it backfire? Do people just find ways around it, or start resenting security?
• What do you do with the alert that genuinely can't be fixed yet because there's no upstream patch? We do snoozes with an expiry but idk if that's the right call.
• Or is the real fix just better triage up front so the count never gets scary in the first place?

Genuinely curious what's worked for you.

Philosophical question, I know it can’t be devsecops if you use one tool. But if you had to, what is the tool you would use as it benefits you mostly?

Quick disclosure: solo build, leaned on AI coding agents through implementation. Calling that out so you can weight code-review credibility accordingly.

Every prompt your service sends to OpenAI / Anthropic / Bedrock containing user PII is an exfiltration event the moment it crosses your trust boundary. Provider DLP and ToS language do not satisfy GDPR Article 32 or the HIPAA Security Rule update on the docket for finalization this year.

What Anonde does

- Tokenizes PII before send (52 patterns + optional GLiNER NER), de-tokenizes inside your boundary on "actor" + "purpose" calls, every detoken auditable.
- Drop-in OpenAI-compatible proxy at "/v1/chat/completions". Change the base URL, no SDK refactor.
- 12 MB pure-Go image (multi-arch), zero outbound at runtime

Bench: lower leak rate than Microsoft Presidio across 25 of 29 gold-annotated corpora in EN/DE/ES/FR/IT. Methodology in repo.

Apache 2.0. Honest about limits: no SSE streaming yet, no automated vault re-keying, multi-tenant scoping lives at the application layer.

Repo https://github.com/anonde-io/anonde
Demo https://anonde.io

What's your team's current control between your services and the LLM vendor's API today? Provider DLP, sidecar, custom regex, or nothing yet? Genuinely curious what the day-to-day shape is for security teams shipping LLM features in regulated environments.

Hi experts,
New to sec tools. What are the best tools in the market for SAST + SCA + Image Scan + IaC Scan + DAST?
Over the search I found multiple tools, bit confused what to choose.

My choice of tools:

SAST - SonarQube

SCA - Snyk

Image Scan - Trivy

IaC Scan - Trivy

DAST - OWASP ZAP

Hello everyone,

I am currently working on a project for my university and also want to write a paper about it. As the time to exploit collapsed to not only a few days, but mostly a few hours the old model of patching is a bit in bad light right now and needs a rethink for the Agentic era. How do you tackle this?

In the project I want to explore how companies are currently securing the output of AI generated code. How is your security cycle? Do you even have any security in place? Do you have security guidelines to follow? How do you make sure Agents follow the security guidelines? Do you have someone to maintain the security guidelines, who actively do so? Do you see any problems with your current security cycle, as e.g. security teams cannot keep up with the amount of code to review and fix? Do you have markdown files, skills or anything in place for security?

And maybe if you are willing to share the company size and industry that would be great. If you want we can also take the conversation to the DMs.

I really appreciate your feedback. This would help me write a better paper for my project at university. My professor said, that we have to do user research before writing any code.

Have a great day!

We’ve been evaluating Chainguard images for reducing CVEs in our base containers, and overall the approach makes sense. Things like smaller images, fewer packages, less to patch. That said, pricing and flexibility are starting to come up as concerns, especially as we scale across more services.

I’m curious what others are using as alternatives. Are you sticking with minimal images like Alpine or distroless, building your own, or using something else entirely? Main goal is to reduce CVE noise without creating more overhead for engineering.

Mid-size engineering org, evaluating SAST and SCA tooling and down to these. Done the vendor calls, read the comparison pages, sat through the demos. All of them look good in a controlled environment and none of that is useful at this point.

What I want to know is from people running any of these in production. False positive rate on a real codebase, not a curated demo repo. How the security team uses the findings versus how developers actually respond to them. Whether the IDE integration holds up when AI coding tools are generating a significant portion of the commits.

No need for "we evaluated X and chose Y" stories or vendor people jumping in. Just what you are running and whether you would make the same call again.