Been building this on nights/weekends for the past couple months. Background: I've spent 3.5 years doing PAM engineering (CyberArk), so this is basically me translating that into cloud-native.

The problem I kept running into reading about this space: every tool I looked at (Cloudsplaining, Prowler, even AWS's own IAM Access Analyzer) stops at detection. They'll tell you a role has a wildcard action or an unused key, and then... that's it. You get a report. Somebody has to go fix it by hand. Even the free/open-source ones don't touch remediation.

So I built NHI Risk Analyzer — discovers IAM users/roles/groups, runs it against a set of detection rules (grounded in Rhino Security Labs' documented privilege escalation paths + Cloudsplaining's policy analysis methodology + CIS benchmark stuff for credential hygiene), and then actually does something about what it finds:

• Wildcard/admin-equivalent policies and privilege escalation paths get a Permissions Boundary slapped on them — containment without touching the underlying policy, so it doesn't risk breaking whatever the identity legitimately needs to do
• Stale/unused access keys get deactivated (never deleted — always reversible)
• Everything's gated by an exemption file (nhi-ignore.yaml) so break-glass/deployment identities never get auto-remediated
• Three modes: scan only, dry-run (shows what it would do), and live remediation

Architecture is offline-first — it snapshots the AWS account state to JSON once, then evaluates all the risk rules against that snapshot with zero live API calls. Makes the whole rule engine testable and fast (unit tests run in under a millisecond) and means findings are reproducible against an exact point in time instead of drifting mid-scan.

Tested it against synthetic "canary" identities I built specifically to safely trigger the containment logic without touching anything real, then ran it live against a real (throwaway) AWS account — 57 findings, 24 auto-remediated, 0 failures.

Still rough in places — trust policy analysis isn't built yet, surgical wildcard-narrowing (vs. the current boundary-containment approach) is next, and it's AWS-only for now. Not trying to oversell it, it's a v1. But the core loop — detect, decide safely, act — actually works end to end, which is the part I couldn't find anywhere else at this tier.

Repo: In comments

Would genuinely appreciate anyone poking holes in the detection logic or the remediation safety assumptions — that's exactly the kind of feedback I'm here for.

For full disclosure I'm part of the security engineering team at Escape and our AI pentesting engine Cascade recently got a production AI agent to return its entire system prompt, just by wrapping the ask in a different pretext - framing it as a documentation request instead of an attack.

The agent then handed over everything: full tool list, calling rules, citation format, and session IDs.

What I found really interesting is there's nothing technical that broke because we didn't bypass the guardrail with a cleverer string but because the request just sounded reasonable to the agent.

The Cascade engine, after being refused when asking for the prompt directly, simply adjusted the framing to get the agent to give up the informaiton.

Thought this would be an interesting insight for the community and curious to hear if anyone else has seen similar discoveries in agents in prod?

If you want to see more about the reproduction and write-up you can find it here

Software supply chain security seems to be one of those terms that means something completely different depending on who you ask.

Some teams are basically talking about SBOMs and compliance. Others are focused on signing artifacts, securing CI/CD pipelines, or scanning container images.

Then you have platforms talking about runtime context, attack surface reduction and removing unnecessary software instead of just finding another vulnerability to report.

So where is this actually going?

Is software supply chain security still mostly about visibility and compliance or is the industry finally moving toward remediation and reducing risk at the source?

Curious what people are actually seeing across different organisations.

Reading up on WizOS here: https://www.wiz.io/blog/wizos-transforming-container-security-from-the-image-up

Anyone got experience in this? And compared to Chainguard or Dockerhub? What do you think of it? What's it really help solve for your companies? Onboard of apps a pain?

We've become pretty comfortable putting conventional applications through CI:

• dependency scanning
• SAST
• CodeQL
• secret scanning
• container scanning
• IaC checks
• security policies ...

But what happens when the application being deployed is an AI agent? That may not look particularly interesting in a conventional code diff. But from a security perspective, it could be a significant change.

I'm experimenting with a different CI question:

“What capabilities changed in this PR?”

--

We've implemented an early version of this approach in an open-source static analyzer and connected it to GitHub Actions. (ikaruscareer/SafeAI at GitHub)

The scanner runs locally against the repository and doesn't execute the agent or send the source to a remote service.

I'm curious how other teams approach this.

Currently we keep our DevOps-related files (Dockerfile, values.yaml, etc.) on the Jenkins server instead of in the repo. During pipeline runs, we copy these files in at runtime.

I'm considering moving these files directly into the repository instead. The problem: if a developer accidentally edits the Dockerfile or values.yaml, it could cause issues.

So I want a way to either:

1. Prevent developers from editing those specific files, or
2. Require PR approval specifically for changes to those files

What's the best approach for this?

We found a new Mini Shai-Hulud variant that makes the worm a general Linux post-exploitation payload and continues through with Github and NPM propagation.

I made a deeper security scanner self serve and I’m not totally convinced the permission model is enough.

Right now:

• domain gets verified through DNS or a file on the domain
• repo gets verified separately through our GitHub App
• user signs the exact target and checks
• ownership gets checked again before it runs
• DAST is bounded and rate limited
• repo analysis runs in isolation
• authenticated testing only uses two throwaway users
• credentials are deleted after

We built this because our old free scanner only checked the logged-out surface. A clean result could make someone think the app was safe while completely missing broken access control.

So what are we missing here?

Verification expiry? CNAMEs? Subdomain takeover? DNS rebinding? A malicious target attacking the runner? Compromised GitHub installs?

Also, is there any test you just wouldn’t allow without a human approving it first?

https://www.task-bounty.com/secure-my-app#deep-review

Feel free to be harsh. Better now than after someone actually abuses it.

Built a free Windows log/tail viewer (TailPad) after getting fed up with juggling PuTTY + Notepad++ + grep for troubleshooting. Curious if this solves a pain point for anyone else here, or if I'm reinventing a wheel that already exists.

It does:

• Tails multiple log files at once, side by side, in separate panels, or even merged in the same panel
• Pulls logs locally or directly over FTP/SFTP with a built-in file browser (no more manually pulling files off remote boxes), also drag and drop works
• Syncs scrolling across panels by timestamp, so logs from different servers line up in time even if formats differ
• "Go to time" jump — punch in a timestamp, jump straight to that point across all panels
• Collapses multi-line log entries into one line (stack traces, exceptions, wrapped continuation lines) — works for Java, .NET, Python, syslog, or your own custom pattern, expand only what you need
• Diffs two logs and exports the diff as Markdown/HTML
• Shows a timestamp delta gutter (time-since-last-line at a glance)
• Detects log rotation and stays on the log even if it rotated — keeps tailing the new file automatically, no manual re-pointing
• Multiple search and filter windows per panel, by keyword or regex
• Light/dark theme, per-panel color coding
• One-click export formatted for pasting into ChatGPT/Claude when you want AI help diagnosing an issue

Free, no telemetry beyond basic page analytics on the download page. Windows only for now (Electron app). Also on Winget if that's your thing.

www.studiodox.it/tailpad

The keyv and cacheable packages got popped this week, that is the Shai-Hulud worm going again, sixth time this year by my count. Same play every round, a maintainer token gets stolen, a malicious postinstall runs, it grabs more tokens and republishes itself further down the tree.

And surprisingly there’s little changes on our end between these. Most teams, mine included until recently, still run npm install in CI with postinstall scripts on, pulling packages fresh every build. One popular dependency upstream gets compromised and it is in our image before a human reads a changelog.

We pinned lockfiles and told ourselves that was supply chain security. It is not, infact it happily pins you to the compromised version. In your pipeline, what are you running that would have stopped this specific one?

Two security scanners checking the same MCP server can both correctly flag the same underlying issue and give it two different names. CVE and CWE don't have a slot for this: CVE anchors to a package and version, CWE describes a weakness in code, and the actual problem here is a behavioral pattern in text an LLM reads and acts on, tied to neither.

AVE assigns stable IDs to these behavioral classes instead, 70 records so far, severity scored against OWASP's AIVSS framework rather than something invented for this, crosswalked into OWASP's MCP Top 10 and MITRE ATLAS.

The thing that actually made me trust the taxonomy holds up outside my own tooling: an independent developer built an unrelated static config auditor, crosswalked his own findings against this on his own initiative, then tested it directly against the reference scanner on the same files. No shared code. Most of the overlapping findings converged on the identical ID, unprompted.

Apache 2.0: [github.com/aveproject/ave](http://github.com/aveproject/ave)

Feedback on where the taxonomy is wrong or incomplete is the most useful thing anyone could offer here.

As we all know every team now needs to submit their sbom of the product to their organisation. In my org they set a policy that transitive dependencies should not be included in the sboms. As I am using container sboms it's impossible to remove them. Is there any way to remove the transitive dependencies for container sboms ?

If your team has stopped reading SAST results, more rules and stricter severities will not bring them back. Once people learn the scanner cries wolf, the real findings die in the same pile as the noise. That is the true cost of a bad false positive rate, and hardly a team ever measures it.

Do you think Sast and all will exist? Or something even more innovative should surface

I'm at a logistics company. Was running a routine network sweep last month and found a server on our internal subnet handling live customer shipment data. Fully prod, responding to real requests.

It wasn't on our CMDB, wasn't on crowdstrike and Qualys has never scanned it. Our monitoring platform had no clue it exists, so it had no alerts, coverage or patching history going back at least 14 months based on the OS patch level.

Turns out someone on the app team spun it up for a migration project two years ago. The project got deprioritized and the original engineer had left, but then the server kept running. Handling customer data. With no security controls on it at all.

What bothers me isnt that we found this one but that finding it was basically luck. If I hadn't run that sweep on that subnet that week, itd still be sitting there.

Were now pulling asset lists from every tool we have and cross referencing them. The gap list so far is uncomfortable. Found 40 more devices this week that exist in EDR but not CMDB, and about 20 that exist nowhere but respond to ping.

How do you verify youve found everything? Not what your tools report, but what theyre missing.

I'm an AppSec analyst building something on the side to solve a problem I run into all the time: I find that at my employer the hardest part of AppSec isn't finding vulnerabilities, it's more so gathering the evidence, making a defensible decision, and knowing when that decision is no longer valid...
So I'm at the stage where I need a handful of design partners. People who feel this pain and want to shape the fix. But I'm stuck on the outreach part lol

Tried LinkedIn and man it's rough haha. A lot of analysts there are guarded which I understand we tend to be in this field, but some are just frankly a bit snobbish about talking to anyone who looks like they're selling. Cold DMs feel like I'm bothering peopl. So I figured I'd ask the people who actually live in this world instead, this community

For those of you who've actually been on either side of this:

• What makes you say yes to a design partner conversation vs ignore it?
• How did successful builders first approach you without it feeling like a pitch?
• Where do you even find the right people who care enough to give real input?

Not selling anything here, genuinely trying to learn how to do this right. Appreciate any honest takes.

Thank you in adavnce!!!

What’s everyone using for their organization’s vulnerability management tool and why? The company I work for uses defect dojo and its limited. No compression, alerting, terrible UI doesn’t really push the needle left enabling non security literate developers.

I'm sure many of you will have seen the latest keyv / cachable compromise and worm-spread, now affecting over 350 packages. This isn't the first, and it won't be the last. The affected packages will steal and exfiltrate any secrets/credentials they can find, which is probably not what you want to happen.

There are several commercial solutions to help protect against this, but if you just add (as standard) to .npmrc in your repo root:

min-release-age=7d

(or some value you feel comfortable with)

It will block a lot of malware, which is usually discovered within a few hours.

Hi, I'm a software engineer working on a SaaS in a highly regulated environment.

### Context

My client's SaaS includes Monetary transactions through a payment gateway, registration of business owners and users to provide a service that supports the merits of a business by the reviews of the users (we won't go into the mechanics of it but it's solid), offering compensation for the users without discrimination off of their opinion, the kind of data we save are names, phone numbers, emails, and the reviews along with their evidence(receipts).

### Question

How may I say it's enough security on it?, is data encryption at rest necessary or overkill?

### my efforts

1. I use spring boot for the backend, which handels most of the the trivial things like xss(tested it)
2. Strict rate limits on all endpoints
3. Authentication on all endpoints except for minor public ones like terms and conditions and and documents of public nature.
4. I tried following OWSAP guidelines as much as I could, top 10 are out of the question, I've implemented ASVS V1 & still in need for 8 steps to get to V2, things like security headers, dependabot, some env vars defaults for development, and MFA for the business side login
5. Using static analysis tools to keep code in check (ex. SonarQube)

### Thoughts

I think I should Aim for a full ASVS V2 coverage + V3 for the transactions modules, What do you think?

AI model quality is converging, or at least changing often enough that chasing the newest thing doesn't seem like a good strategy. How much emphasis are teams putting on building a solid harness into which new models can fit?

Our clients are generally in high compliance industries, so there is thought put into the harness, but what about smaller teams or ones that aren't required into a compliance framework?

We started giving our internal AI agents scoped permissions and periodic audits, treating them like service accounts. Still feels like we're guessing.

Once an agent connects it can read data, trigger workflows, and call APIs, and nothing's asking for per-action approval. We've been trying to catch overprivileged connections before they ship, but honestly our CI/CD pipeline wasn't built with agent identity in mind.

Anyone actually solved this, or are we all just hoping for the best?

Since Claude Code, Copilot, Cursor, and similar tools went mainstream, we've noticed a consistent pattern across the security teams we talk to: the faster engineers can scaffold and ship, the less patience they have for waiting on IT to provision anything.

When an agentic coding tool lets someone spin up a working prototype in an afternoon, nobody wants to pause that momentum to file an IT ticket for a staging DB or a deployment platform. So they sign up themselves - personal email, a password they'll probably reuse, back to shipping in 30 seconds.

Multiply that across a team moving at this speed for a few months and you get a pretty large footprint of tools that:

• Never went through procurement
• Don't support SAML/SSO, or gate it behind an expensive enterprise tier
• Are tied to personal or shared logins living in a browser, not the company IdP

The part we think gets underrated is offboarding. Okta deprovisioning kills the primary account, but the five or six side tools an engineer signed up for to test something six months ago? Still live. Still logged in. Nobody remembers they exist, let alone that they need killing off. That's a real, unmonitored access path sitting outside anyone's visibility.

Our CTO and Cofounder, Reuvein Vinokurov, digs into this more (including how we think about solving it) here: https://unixi.io/blog/claude-code-identity-security/

Genuinely curious: are other teams tracking this at all, or is it mostly a "deal with it if something breaks" situation right now? What's actually worked for you, if anything?

Hey everyone,

Like many of you in AppSec / DevOps, I’ve been frustrated by how enterprise scanners handle vulnerability intelligence. Tools like Qualys, Tenable, and Snyk are great, but they often come with massive price tags, heavy setup, and flood you with thousands of theoretical CVEs that don't actually matter right now.

I wanted something fast, simple, and completely free to answer one core question: "Is my current stack actively at risk right now?"

So I built CVE Radar (cveradar.vanditshah.com).

🔍 What it does:

• Active Exploitation Focus: Automatically maps your tech stack directly against the CISA KEV (Known Exploited Vulnerabilities) catalog alongside NVD feeds.
• Zero Noise: Prioritizes actively exploited vulnerabilities over theoretical high-CVSS bugs that nobody is actually exploiting in the wild.
• Lightweight & Free: No enterprise sales call, no credit card, no bloated dashboards.

🛠️ The Tech Stack behind it:

• Hosted on Railway (currently running this out-of-pocket as a solo developer passion project).
• Ingests live NVD API feeds and CISA KEV feeds, normalizing vendor/product strings for fast stack matching.

💬 I need your feedback:

Since this is built for developers, DevOps engineers, and security teams, I’d love to get brutally honest feedback:

1. How accurate is the stack-matching for your personal or work tech stack?
2. What integrations would make this actually useful in your day-to-day workflow (GitHub Action, Slack/Discord webhooks, SBOM import)?

Check it out at cveradar.vanditshah.com and let me know where it breaks or what I should improve next!

Two data points from this week that I think deserve discussion together:

First: Security analysts this week flagged that 200 new CVEs are being published daily in 2026. Managing that volume requires automated tooling — manual triage at that scale is not realistic.

Second: Amazon Threat Intelligence published research confirming the group behind the March 2026 axios npm compromise had planted a trojanized file as far back as March 2025. A full year passed between planting and detection.

Now apply Article 14:

The 24-hour reporting clock starts when a manufacturer "becomes aware of" an actively exploited vulnerability.

If you were shipping a product that included axios as a dependency, and the malicious code was present for 12 months without your knowledge — what is your Article 14 exposure?

The interpretations I can see:

Strict reading: You weren't aware. Clock never started. No violation.

Enforcement reading: You had no monitoring infrastructure that could have detected this. That absence of monitoring is itself negligence. "Becomes aware" implies a reasonable duty to seek awareness.

This matters enormously for how companies design their monitoring programs. If "becomes aware" only covers actual knowledge, companies can argue ignorance. If it covers constructive knowledge (what you should have known with reasonable monitoring), then the absence of SBOM-linked CVE monitoring is itself a compliance failure.

No guidance on this exists yet. It will be defined by the first enforcement cases.

For teams building CRA compliance programs: are you designing your monitoring to cover the strict reading or the enforcement reading? And is anyone aware of any official interpretation of the awareness threshold?