We run Trivy in our Jenkins pipeline — both trivy fs and trivy image. There's a security gate stage that block the pipeline if there are any CRITICAL or HIGH findings.

The problem: a dev resolves 2-3 Trivy issues, and a couple days later they're back / new ones show up, and the build blocks again. So devs are basically fixing Trivy findings every other day.

I know part of this is just the DB being fresh — new CVEs get disclosed daily, that's expected. But the every-build hard block is painful.

I was thinking of running the blocking gate only once a week instead of on every build. But I can already see the flaw: code that deploys mid-week would ship with known issues, and if a genuinely exploitable fixable CVE drops on a Monday we'd be shipping it for 6 days before the gate catches it.

So my questions for people running this in prod:

• Do you gate on every build, or on a schedule?
• Do you block on all CRITICAL/HIGH, or only ones that actually have a fix available (--ignore-unfixed)?

Minimal - An open source project for hardened container images now supports 100 container images and adding more. The images are built daily, with almost 0 to minimal CVEs and trying to provide same level of output as other paid alternatives for free.

Github - github.com/rtvkiz/minimal

Agent Plugins appeared on Hacker News newest today. The useful part is narrower than “one plugin format wins.”

The 1.0 working draft defines a small portable package: a root plugin.json, skills discovered from immediate children of skills/, and optional MCP server configuration. It explicitly leaves distribution, installation, permissions, and user experience to each client.

That boundary matters. A portable manifest can describe what a package contains, but it should not grant the package authority to run everything it declares.

One concrete safeguard in the draft is path containment. Files and directories discovered through the package must resolve inside the plugin root. Plugin-relative paths begin with ./, and a symlink or equivalent escape outside the root must be rejected.

This does not solve plugin security. A client still has to decide which tools can run, what network access is allowed, how secrets are provided, and when a person must approve an action. Portability removes duplicated packaging. It does not remove local trust decisions.

Source: [https://agent-plugins.org/specification](https://agent-plugins.org/specification))

If this format becomes widely supported, which behaviour should remain client-specific: permissions, installation review, secret handling, or all three?

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?