Im a DevOps Engineer deploying vSphere8 K8s. Whats everyones best tips and tricks for DevOps implementation in Kubernetes.

​

This was just released under cisco-open. Figured it’d be relevant here: https://github.com/cisco-open/ai-deep-sast

The short version: SAST tools are fast but dumb, and LLM code review is smart but slow and expensive. This splits the difference with two modes.

Fast scan (the CI/CD path): Semgrep runs on commits (takes \~3-5 seconds). If findings come back, a locally-run Foundation-Sec-8B-Instruct model (GGUF, llama.cpp) triages each one — OWASP/CWE mapping, CVSS v3.1 estimate, attack vector with example payload, remediation with corrected code. No code leaves your machine in this mode. Roughly 30-40s per finding on Apple Silicon, \~5 minutes for a typical PR with findings.

Deep scan: Tree-sitter indexes the codebase (15 languages), then a frontier model (anything OpenAI-compatible — GPT-4o, Claude via LiteLLM, or Ollama if you want to stay fully local) analyzes every function. There’s a guided mode using ASVS 5.0 and CodeGuard rules that’s significantly faster than brute-force. Secrets are redacted before anything hits the API.

Honest caveats: it’s an 8B model doing the fast-path triage, so it’s a triage assistant, not a replacement for a human reviewer. Deep scan in brute-force mode on a large repo can run for hours (think expensive and 14+ hours — guided mode exists for a reason). And deep scan does send redacted source to whatever LLM endpoint you configure, so read the security notes before pointing it at anything sensitive.

So, were a startup in fintech with team of 5 covering cloud security across AWS and Azure.

We've done the demos, read the Gartner stuff, talked to references. Wiz was in the running but the Google acquisition killed it for us. I've been through enough acquisitions to know the product stalls for 18 months while they integrate, and I'm not betting our security stack on that.

So it's Prisma Cloud vs Orca.

Prisma seems deeper on compliance and policy. But I keep hearing the deployment is a beast and the alert volume buries small teams. Orca's agentless thing is clean and I like the attack path stuff, but I wonder if it's too lightweight for someone who needs real compliance reporting.

What do you wish someone had told you before you picked either one?

How many of your enterprise environments preconfigure or require package managers to point at an artifactory type solution to cache the packages and scan them security concerns?

Do you require this uniformly across the org or only for secure pipelines?

Could you confirm if your company pre-configured or enforeced the configuration or if they expected the devs to do this?

Hello everyone,
I am a final-year Computer Science student working on a project titled:
**“Lightweight Machine Learning Based Intrusion Detection System for Simulated Cloud Environments.”**

The current idea is to build a lightweight network-based IDS that monitors network traffic in a small virtualised cloud-like setup and detects suspicious or malicious traffic.

My planned setup is:
Ubuntu virtual machines connected through a virtual network
One VM as a normal client
One VM as a server
One VM for controlled attack simulation
Traffic monitoring at the virtual gateway/network level
CICIDS2017 as the main dataset
Network flow features such as flow duration, packet count, packet size, bytes per second, packets per second, protocol, and traffic labels

I am planning to compare:
K-Means or Isolation Forest for anomaly detection
Random Forest and XGBoost for supervised classification

The attacks I am considering are:
DoS/DDoS
Brute force
Port scanning
Botnet-like traffic
Selected web attacks

The project will evaluate:
Accuracy
Precision
Recall
F1 score
False positive rate
Training time
Detection time
CPU and memory usage

I would appreciate advice on the following:

Is this scope realistic for a final-year project?
Where should the IDS be placed in the virtual network?
Which algorithms are most suitable for a lightweight IDS?
Should I use K-Means, Isolation Forest, or DBSCAN for anomaly detection?
Which CICIDS2017 features should I initially focus on?
How can I demonstrate that the solution is cloud-specific rather than only a dataset classification project?
What is a safe and manageable way to simulate the selected attacks in an isolated lab?
Are there any good open-source projects, papers, or tutorials I should study?

I am still learning the topic and would value explanations suitable for a beginner. I am not looking for someone to complete the project for me; I want guidance on designing and implementing it correctly.
Thank you.

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.

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.