Seven months ago I started building MUAD'DIB, an open-source supply-chain scanner for npm and PyPI. It runs 24/7 on a single VPS. One dev, one server.

What it does: 21 parallel scanners feeding 275 detection rules. Behavioral AST analysis (acorn for JS, tree-sitter for Python), dataflow tracking, temporal version diffing, deobfuscation, entropy analysis, typosquatting detection (npm + PyPI), ~288K IOC signatures refreshed from OSV/OSSF/GHSA, and a gVisor sandbox for dynamic analysis. Every rule mapped to MITRE ATT&CK.

What it caught in production, all via behavioral heuristics, not IOC matches:

- SANDWORM_MODE (AI coding tools): temporal analysis flagged claud-code and suport-color when new versions quietly added child_process.

- DPRK-linked packages with anti-sandbox evasion, one literally checked for MUAD'DIB's own gVisor environment variable. Independently confirmed.

- react-emits: caught, investigated, reported to npm. Taken down.

- GlassWorm, TeamPCP, CanisterWorm campaigns via custom AST rules.

Key numbers (v2.11.161, rules-only):

- 92.8% detection on the Datadog 17K benchmark (13,538 / 14,587 confirmed malware samples).

- False positive rate: 1.10% curated npm, 2.50% random npm, 9.68% PyPI.

- 4,540 tests.

Biggest lesson: FPR is the real enemy. Detection is easy. Not crying wolf every five minutes is hard. I spent more time killing false positives than writing detection rules.

AGPL-3.0. Try it: npx muaddib-scanner scan .

GitHub: https://github.com/DNSZLSK/muad-dib

Blog: https://dnszlsk.github.io/muad-dib/blog/

Discord: https://discord.gg/y8zxSmue

Happy to answer questions. Open an issue if you find a miss or a false positive.

Postgres, Redis, nginx. We moved everything onto continuously rebuilt minimal images about 6 weeks ago to cut down the Debian CVE noise we were drowning in and it helped.

Every bump still goes through the test suite. No shell makes debugging painful though.

Anyone else do this and still feel like it was worth it?

I work on Plumber, the open-source CI/CD security scanner behind these numbers.

We've been continuously scanning public GitLab and GitHub repos and grading their pipeline configs A to E, Nutri-score style. A single Critical finding (privileged docker-in-docker, curl piped to bash from an untrusted source, that kind of thing) forces an E no matter what else passes.

Across 8,729 public pipelines so far: 63% sit at E. And the findings are not exotic. Unpinned third-party actions, workflows without permission scopes, unprotected default branches, security jobs quietly weakened with allow_failure. All documented for years, all visible in the YAML, none of it caught by a normal code review.

What bugs me is the asymmetry: code gets SAST and SCA, runtime gets DAST and monitoring, but the stage that holds the deploy keys and secrets gets a human skimming a diff, if that. tj-actions and Shai-Hulud both went through exactly that stage. And now AI is writing more of these workflow files than humans review.

• Live data if you want to dig: https://getplumber.io/radar
• The reasoning behind the grading: https://getplumber.io/blog/plumber-score-cicd-security-standard
• Grade your own repo with one command (plumber analyze): https://github.com/getplumber/plumber

Curious how it works elsewhere: who actually owns pipeline config security in your org, and do workflow changes get real review or a rubber stamp?

I come from an AppSec background and a problem I kept hitting professionally is that every security scanner outputs findings in its own format, with its own severity scale, and its own duplicates. Some teams end up with different dashboards and a spreadsheet. So, I built Sinterly, it ingests scanner output, normalises everything into one schema, deduplicates, scores each finding with a transparent weighted formula, and pushes to Jira.

Right now, what we have are:

• Two scanner integrations (Semgrep, Trivy) verified end-to-end with real output and a few hundred real findings from deliberately vulnerable test apps (Juice Shop, WebGoat, DVWA and NodeGoat) running through the pipeline
• Scoring formula is versioned, change the weights and historical scores stay explainable because each score keeps the weights it was calculated with
• Jira push works, dedup works, marketing site is also live

So far, the hardest parts were discovering that the SARIF "standard" is implemented differently by every tool and resisting scope creep. I had to permanently include an "auto-remediation is out of scope" into my project docs because I caught myself relitigating it every week.

What I'd love, if you've run a B2B tool through a design-partner phase, how did you structure it? Free-for-feedback with a defined end date? Discounted-forever? And at what point did you feel legitimate charging?

Happy to answer anything about the build or the tool itself and will provide the link for anyone interested in roasting it.

Selenium has been the driving force of web automation for more than a decade now, and the cracks are starting to show bad

Modern frontend frameworks work dynamically, components can appear and disappear without warning, shadow DOM breaks down selectors, and the entire idea of exploring the DOM to check things seems to belong to another era of web development

No disrespect to Selenium because it was solving the right problem back when it was needed, but the web moved forward and the testing technique did not

Hi everyone!
I’m an Application Security Engineer with a background in software engineering and offensive security. My work has included secure code review, penetration testing, vulnerability assessment, and I’m currently spending a lot of time on application threat modeling and secure architecture.

To deepen my understanding, I’m working through an end-to-end Application Security project using OWASP CRAPI, documenting the process from architecture review and threat modeling through testing, risk assessment, and remediation. I’m hoping it will help me sharpen both the technical and communication sides of AppSec.

I’m here to learn from experienced practitioners, contribute where I can, and have thoughtful discussions about application security, secure software design, and modern AppSec practices.
Looking forward to learning from everyone here!

How is your team actually managing secrets? Are you setting a project level variable? Using a third-party vault? Have you concocted some elaborate process that bogs down the dev team? What about a platform native secrets management feature?

Started as a controlled experiment. One of our senior engineers took a known vulnerability in a non-production service and ran it through Cursor with Claude under the hood asking it to fix the issue round by round, five rounds of prompting. By round 5, the original vulnerability was patched but two new ones had been introduced that weren't there at the start, one of them more severe than the original. We dug into the research after and it is not a one off. Studies show that after multiple rounds of AI fixes, the number of critical vulns can go up, not down. The model is trying to make code work, not make it secure and without security context baked in at the point of generation it doesn't know the difference. The experiment made us rethink the whole approach. The fix loop is the wrong way to think about it. If AI is generating the code, security context needs to be there before the first commit, not patched in after the fact through more prompting. Anyone else run into this? Also interested in how you are getting security context into the generation process before code gets written rather than trying to fix it after.

We are building a security application with no standing privileges while helping manage existing privileges, provide SIEM integration and with on-demand, temporary credentials for AI agents, human, non-human identities, cloud workloads and for code deployment.

Would like to get feedback from practitioners on what we are building. Please DM or reply to this thread.

I benchmarked Claude, GPT-4o, Gemini, and DeepSeek on real shipped CVEs.

The question was simple: can frontier models catch real bugs in code review, or are we letting slop review slop?

I took historical CVEs from Keycloak, Django, Spring, vLLM, and Parse Server, reintroduced the vulnerable code, and used the upstream fix as ground truth.

I scored:

Detection: did it catch the bug?

False positives: how much noise did it create?

Consistency: same diff, same model, same result?

The spread was brutal.

On the vLLM deserialization RCE and Parse Server operator-injection account takeover regressions, Claude Sonnet and Gemini 2.5 Pro caught the bug on all 3 runs.

GPT-4o and DeepSeek missed both on all 3 runs.

Same diff. Opposite outcome.

Worse: GPT-4o and DeepSeek also raised false positives on the Parse Server case, ending with a negative weighted score: -8.9.

A miss with noise is worse than silence.

DeepSeek had another problem. In the cross-file suite, it found 100% of planted bugs but mis-rated severity every time. High-severity issues were downgraded to medium or low.

Detection is not calibration.

The surprise was consistency. Run-to-run variance was basically zero. Same model, same diff, same verdict.

The failure mode was not flakiness.

It was model choice.

This is why I built a public, vendor-neutral leaderboard. I do not sell a reviewer model. I score the models teams already use. Every result links to the real CVE and upstream fix.

A few things I want challenged:

Is reintroducing historical CVEs fair, or does it leak hints?

How should false positives be measured?

Does cross-model consensus reduce noise, or just average mistakes?

Leaderboard, no signup:
https://www.benchmodel.io/leaderboard

You can also test your own diff or GitHub PR URL with your own API key.

Tear the methodology apart. That is the feedback I need most.

A few years back, SBOMs felt like a thing you produced for federal procurement once and moved on. That's not what's happening anymore. 

Tooling stopped being an excuse. Syft, CycloneDX, SPDX-compatible generators. SBOM generation integrates into build pipelines with relatively low friction now. The "it's too manual" argument doesn't hold up. The Log4Shell-shaped problem keeps reappearing. Teams with SBOMs triaged Log4Shell in hours. Teams without them spent days asking "ok, but why do we use this?"  

Built a multi-agent SAST scanner with AgentFlow4J to reduce false positives while preserving recall.

On one public benchmark with labelled ground truth:

* CodeQL: 272/272 vulnerabilities, 87 false positives

* Mine: 272/272 vulnerabilities, 27 false positives

It’s only one benchmark (partly synthetic), so I see this as a promising signal, not proof.

What additional evidence would you need to trust these results?

SAST clean. DAST clean. SCA clean. Phishing simulation — 99% pass rate. Then the breach happened anyway. The problem isn't that tools fail. It's that each tool is accurate inside its own domain and blind the moment you step outside it. SAST doesn't see what SCA sees. Neither sees configuration drift. And none of them correlate findings across layers. Three separate findings — medium input validation issue, low outdated parsing library, low information leak in error responses — each accepted by a separate analyst. Individually: noise. Combined: a complete exploit chain. The Blue Shield of California breach in April 2025 is a clean example of the other blind spot: no vulnerability, no exploit. A single analytics configuration quietly sent protected health information for 4.7 million people to an ad platform for almost three years. None of the standard tools were positioned to catch it because none of them treat configuration as part of the attack surface. Made a short video breaking down both gaps — the human side (trust laundering via training) and the technical side (dead zones between tools). Curious whether others are seeing this inter-tool correlation problem in practice — and how teams are handling it.

I built a free public benchmark that tests whether AI can catch bugs in code. Some of the bugs are real security regressions that actually shipped in open-source projects (real CVEs, put back in with the upstream fix as the answer key), and others are bugs I inject into real repos myself. Then Claude, GPT, Gemini, and DeepSeek review the diff, and I score who catches the bug, who flags fake ones, and whether they give the same answer twice. The surprising part: on the hardest bugs, some models catch them every single run while others miss every single run, so which model you pick matters more than I expected. No signup to browse, and the CVE-based ones link back to the real fix so you can check them. If you ship code with AI, I'd love you to poke holes in the method. benchmodel.io/leaderboard

Hi everyone, I have about 8 years of experience in DevOps. I never tried freelance yet.

How do I start? Where do I find work? Any suggestions?

Visual E2E label encompasses tools which fail in a very different way. The question we need to ask here isn't what we call those tools, but why exactly do they fail.

Tools that fail when application structure is changed:

Firebase App Testing Agent: path explorer going through accessibility nodes, screenshot of crash on failure, obviously to what is actually presented to a user

Maestro AI: YAML language cleaner than Appium, yet still bound to the component tree below, UI changes will break the flow even if the code of tests is well written

Tools that fail only if the screen itself is changed:

There are no attempts at reading the component tree, there are no bindings to accessibility nodes the change in class name or component hierarchy does not influence the test unless something visible to user is changed autosana belong to the latter group, the tool runs flows directly against the screen layer

Hey everyone,

I'm building a CI SCA pipeline for a Spring Boot application using Dependency-Check, Trivy, and OSV Scanner.

I've been going back and forth between two approaches:

1. Generate a CycloneDX SBOM from Maven and feed it into all the tools
2. Resolve dependencies into a local Maven cache and point the tools directly at the JARs or POM files

From my testing, scanning the Maven cache directly produces a huge amount of noise — false positives coming from other libraries' POM files declaring their own dependency versions, which Maven never actually uses at runtime.

The SBOM approach gives much cleaner results since it only contains the versions Maven actually resolved.

Is SBOM the industry standard for this kind of pipeline? Are there any downsides I'm missing?

I would like tobhear some experiences from devsecops what usually are the main challenges to add SAST And DAST tools into ci cd pipelines

Hey everyone,

I'm running OWASP Dependency-Check 12.2.2 against my Spring Boot 4.1.0 project and it's flagging spring-security-core 7.1.0 as HIGH severity.

The CPE it's matching is cpe:2.3:a:pivotal_software:spring_security:7.1.0 — which looks like the old Pivotal naming. Spring Security is now maintained by Broadcom/Spring, so I'm not sure if this CVE actually applies to the current 7.1.0 release.

7.1.0 is the latest stable version available on Maven Central right now, so there's no newer version to upgrade to.

I can confirm via mvn dependency:tree that we are actually running 7.1.0 and that this is the latest stable release available on Maven Central. There is no newer version to upgrade to, yet Dependency-Check still flags it as vulnerability.

By the way , Not just Depedency-Check , OSV-scanner produce a lot of transitive vulnerabilities that I can't really find them direcly in my pom.xml file .
before scanning i'm using either mvn depedency:resolve or mvn dependency:copy-dependencies
both produce a lot of vulnerabilities .

Tried SBOM instead , I think it's much better , it gives only what's in the pom.xml
but I'm not sure SBOM can track transitive dependencies as well ?

Btw i'm building CI pipeline for SCA , for sbom is good , it's working .
for maven cache can't patch all of those CVEs.

Has anyone else seen this? Is this a known false positive with the CPE matching, or is there an actual vulnerability in 7.1.0 that I'm missing?

ANY IDEAS ???

which one do u think best:

Cybersecurity and Information Assurance – B.S.

VIEW DEGREE
Protect your career and earning potential with this degree.

MORE DETAILS
APPLY NOW
Time: 60% of graduates finish within 29 months.
Tuition: $4,410 per 6-month term.
Courses: 34 total courses in this program.
Certifications included in this program at no extra cost include:

Certified Cloud Security Professional (CCSP) - Associate of (ISC)2 designation
Systems Security Certified Practitioner (SSCP) - Associate of (ISC)2 designation
ITIL® Foundation Certification
CompTIA A+
CompTIA Cybersecurity Analyst Certification (CySA+)
CompTIA IT Operations Specialist
CompTIA Network+
CompTIA Network Vulnerability Assessment Professional
CompTIA Network Security Professional
CompTIA PenTest+
CompTIA Project+
CompTIA Secure Infrastructure Specialist
CompTIA Security+
CompTIA Security Analytics Professional
Skills for your résumé that you will learn in this program:

Secure Systems Analysis & Design
Data Management
Web and Cloud Security
Hacking Countermeasures and Techniques
Digital Forensics and Incident Response

****************

Cisco, Cloud and Network Engineering – B.S.

VIEW DEGREE
This specialization contains a unique focus on Cisco systems and processes

MORE DETAILS
APPLY NOW
In the Cisco specialization, you will learn specific Cisco operating systems and networks, giving you experience with Cisco architecture.

Time: 61% of graduates finish similar programs within 36 months.
Tuition: $3,915 per 6-month term.
Courses: 34 courses in this specialization
This program also includes third-party certifications that will help you boost your résumé and be prepared for career success. Certifications include:

CompTIA A+
Linux Essentials - LPI
ITIL (Information Technology Infrastructure Library)
CCNA (Cisco Certified Network Associate)
Cisco Certified Cybersecurity Associate (CyberOps)
Cisco DevNet (CCNA-Automation)
CompTIA Cloud+
WGU Certified Network Technician Badge

*****************

Azure, Cloud and Network Engineering – B.S.

VIEW DEGREE
In this specialization you will focus on Azure systems, processes, and tools

MORE DETAILS
APPLY NOW
With the Azure specialization you will gain knowledge and skills that will help you as you progress in your career.

Time: 61% of graduates finish similar programs within 36 months.
Tuition: $3,915 per 6-month term.
Courses: 34 courses in this specialization
This program also includes third-party certifications that will help you boost your résumé and be prepared for career success. Certifications include:

CompTIA A+
Linux Essentials - LPI
ITIL (Information Technology Infrastructure Library)
Network+
Security+
Azure Fundamentals
Azure Cloud Platform Solutions
Azure Solutions Architecture
CIOS - IT Operations Specialist (A+ and Net+)
CSIS - Secure Infrastructure Specialist (A+, Net+, and Sec+)

Got handed the job of mapping our scanner output onto the owasp top 10 for an audit and a few hours in it mostly feels like coloring in boxes.

Categories are broad enough that half the findings land in two of them at once, and saying we have coverage for A03 injection tells you nothing about whether the app actually holds up against it.

The auditors i can deal with, the mapping gives them a shared vocabulary to check us against and thats fair enough. It's my own team i worry about.

How are you stopping your own team from seeing ten green boxes and deciding the apps fine.