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

@lateos/npm-scan now detects:

• Dependency Confusion (spoofed internal URLs + inflated semver)
• Typosquatting (react→reacct, webpack→webpakc, etc.)
• Credential Harvesting (fs + network exfil + hardcoded tokens)

85–95% accuracy, <2% false positives. Works offline.

npm install -g @lateos/npm-scan

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.

RedAccess just published the Shadow Builders report (covered by WIRED, THN, VentureBeat this week), and the numbers are genuinely harder to dismiss than I expected.

**What they found:**
- 380,000 publicly accessible web assets across major vibe-coding platforms (Lovable, Bolt, Cursor etc)
- ~5,000 appeared to be built for corporate use
- 2,000+ of those were exposing sensitive data — clinical trial records, financial data, shipping manifests, customer PII — to anyone with the URL
- No credentials required. Passive scan only.

**The structural problem they're flagging:**

This isn't old Shadow IT (buying Trello on a corporate card). These apps are custom-built, directly integrated with CRM/ERP/BI production systems, and published externally. They don't exist in any CMDB, don't show up in vuln scanners, and the employees building them don't know they're creating a security surface. CVE-2025-48757 documented Supabase RLS being skipped in Lovable-generated apps — 170+ production systems affected.

**My question for the community:**

How are your orgs actually handling vibe-coded app governance? I'm seeing a few approaches floated — browser-layer DLP, mandatory pre-deployment checklists, procurement gating — but nothing that feels like consensus yet.

Also curious if anyone's run a passive scan of their own org's public web footprint specifically looking for AI platform subdomains. RedAccess did it at scale; you can probably do a rough version with shodan or similar.

I previously covered the Megalodon GitHub Actions supply chain attack — same underlying pattern of developer tooling moving faster than security governance — here if you want background on the CI/CD layer angle: https://www.techgines.com/post/megalodon-github-actions-supply-chain-attack-safedep-2026

Full writeup on the Shadow Builders findings here: https://www.techgines.com/post/vibe-coding-security-shadow-builders-exposed-apps

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.

Most SCA tooling is built for org-scale workflows (Snyk, Dependabot, Renovate per-seat platforms). If you're solo or running a small team with a portfolio of projects — your own infra, side projects, internal tools — there's a gap: you want continuous SCA monitoring across every project you ship without paying per-seat for a commercial platform, and npm audit per-checkout is not a workflow.

I built Sentinello to fill that gap for myself. It's a self-hosted portal you point at your code roots. It runs the native audit (npm, pnpm, yarn) on every project on a schedule, surfaces every CVE in one dashboard with severity filters, tracks per-project history so you can see when something regressed, and fires Slack/Telegram/webhook alerts. Webhook payload is structured JSON with the full dep path + recommended fix version, so you can pipe it straight into an auto-fix agent.

Ops bits worth calling out for this sub:

• Uses the native package-manager audit, not a reimplementation of the advisory DB, so findings match what engineers see locally
• HEALTHCHECK + /api/health endpoint (SELECT 1 against SQLite)
• Scan cadence 1h to 24h, anchored to a start hour and timezone you pick
• Per-target alert scope (everything / specific roots / specific projects) and severity filter
• Two webhook payload shapes: structured JSON for auto-fix agents, or a plain-text markdown advisory ready to pipe into an LLM
• Single Docker container, SQLite, multi-arch (amd64 + arm64)
• MIT, no SaaS, no telemetry, no signup

https://sentinello.org https://github.com/walkofcode/sentinello

Feedback welcome, especially from anyone wiring continuous SCA into a small-team workflow. Curious what alert routing rules you'd want that aren't there yet.

The API management decision in 2026 is really an architecture question about how many control planes you want to run.

Gravitee handles rest apis, kafka event streams, and ai agent traffic from one policy engine with deny-by-default authorization at the wire level and zero ambient permissions per agent. If the architecture spans traditional api traffic, events, and ai agents, the practical question is whether you want one governance layer or three separate tools that don't share a policy model.

Kong has the strongest plugin ecosystem and community knowledge of any open source option. Now actively building a2a and agent gateway support onto the platform, worth pressure-testing whether that governance layer actually runs on the same policy engine as the rest of the api management or sits adjacent to it

AWS Bedrock AgentCore now covers a2a for multi-framework agents alongside mcp tool governance. For primarily aws architectures this handles the agent governance question well. The architecture question worth asking is what happens to governance at the boundary when something runs outside aws.

Tyk is the practical call when kong's operational overhead isn't justified by the use case. Core api management, lighter footprint, smaller community.

Apigee has the deepest api lifecycle management inside gcp.

Agent governance is roadmap. For teams that need it now, that's a concrete gap not a theoretical one.

The question that frames the whole decision: do the api governance policies and agent governance policies run on the same engine, or are you wiring separate systems together?

The migration itself is going fine. Transport requests are moving, the basis team knows what they're doing, cutover planning is on track.

The problem is security monitoring. Our security team came from on-prem and their entire playbook is agents. They want agents on every instance, including production SAP. Basis team says absolutely not, they've seen agents tank performance on HANA before and they're not risking it during a migration that's already on a tight timeline.

So now we're in this deadlock. Security won't sign off on go live without visibility. Basis won't allow agents. Management keeps asking about compliance readiness and I have no answer that satisfies anyone.

We're about 8 weeks from cutover and this is the thing that's going to delay us, not the actual technical migration.

For anyone who's been through this how did you handle this stalemate? Just curious if you found a middle ground or did you find a way to monitor agentlessly? Thanks all

Most discussions around AI coding agents focus heavily on model quality, but I think the more important long-term problem is operational reliability.

As agents move beyond autocomplete and start interacting with CI/CD systems, Kubernetes clusters, Terraform workflows, logs, deployments, and internal APIs, the surrounding operational environment becomes more important than the model itself.

That’s where the idea of “harness engineering” is starting to emerge.

The core idea is:

Agent = Model + Harness

The harness is everything around the model that makes it safe and operationally useful:

• execution boundaries
• verification loops
• observability
• policy controls
• rollback safety
• permissions
• auditability
• memory/state
• approval gates

From a DevOps perspective, this feels less like a completely new discipline and more like an evolution of things we already do through CI/CD, platform engineering, SRE practices, and policy-driven automation.

I wrote a long-form breakdown covering:

• prompt engineering → context engineering → harness engineering
• why DevOps teams are well positioned here
• how AI agents change operational assumptions
• practical use cases around CI/CD, Terraform, Kubernetes, and incident workflows
• security risks like prompt injection and over-permissioned agents
• why strong pipelines matter more than frontier models in many cases

Would love to hear how others are thinking about operational controls around engineering agents.

Issues for ~ the last 2 hours

We have a software product that is designed to run on a customized Windows 11 image that we apply to all devices on which our software runs. Now, for our software, we have created an SBOM that covers all components that it consists of. But this product is used in a highly regulated industry which is why we were asked to also provide an SBOM for the Windows image itself.

While we have a very good idea how to create an SBOM for our software, the approach that we should take to create the SBOM for the Windows image is less clear. Running your typical SBOM generation tools on a file level where each file ends up as an entry in the SBOM does not seem to make much sense.

I think it would be more useful to extract the exact Windows version in the image, extract a list of Windows updates, installed software, etc. and build the SBOM from that information. But building a tool manually to achieve all this seems to be time consuming and we might miss things that we should include.

So, I'm looking for practical guidance of how to generate an SBOM for a Windows image. Has anyone done this before? How did you do it and what tools did you use?

Compliance-aware AI appears in a lot of vendor materials. Almost none of them define what it means at the implementation level and the ones that do seem to mean different things.

From a devsecops perspective, a tool generating code that's compliant with generic secure coding best practices is not the same as a tool generating code that reflects your organization's specific regulatory requirements. HIPAA has different constraints than PCI-DSS. Code touching CUI has different constraints than code that doesn't.

The distinction I care about is whether the compliance context is incorporated into generation or applied as a linter after the fact. Those are different architectures with different assurance levels. Generating code and then checking it against compliance rules means violations get created and then caught. Incorporating compliance constraints into generation means violations are less likely to be created at all. How are you verifying which one a vendor is doing? The sales answer is always the stronger one.

Our GRC team has been asked to evaluate AI coding assistants for a financial services client. The evaluation criteria differ significantly from what most developer focused reviews cover.

The questions GRC cares about are data residency, retention policies, audit trail availability, model training on client data, and whether the tool's secure context layer can be isolated within the client's security perimeter.

The secure context layer requirement means the tool's organizational memory, the indexed codebase, the retrieval infrastructure, and the prompt logs all need to stay within a boundary that the client controls and can audit. SaaS tools where that data flows through vendor infrastructure typically fail this evaluation immediately regardless of their SOC 2 status, because SOC 2 Type 2 certifies vendor controls over that data but doesn't put the data inside the client's perimeter.

We've been through initial screening with a handful of tools. The field narrows fast once you apply the on-premises context layer requirement. Most tools that claim on-prem support are running inference locally but still phoning home for retrieval or telemetry. One that cleared that bar for us was tabnine. Fully on-premises including the context layer, SOC 2 Type 2, GDPR, ISO 27001, ISO 9001, and zero-retention by design. For anyone who has done a formal GRC evaluation of AI coding tools, the gap between marketing claims and documented architecture is very significant.

Curious what the SOC/MSSP crowd thinks.

Do you actually need cross-SIEM query translation in your day-to-day (SPL → KQL, Sigma → Chronicle, etc.), or is it more of a nice-to-have?

And if you do need it — are the tools already out there (sigma-cli, UNCODER, manual rewrites) getting the job done, or are you still hitting walls?

I'm a self-taught developer working in an operational department at a large finance company, not on any techical team. With approval from higher-ups, I built a Node.js tool that will be used to replace a large amount of manual work. It handles personal data of around 10,000 people and processes millions of euro's in yearly transactions. It also has access to our company's portal, where many more more clients are registered.

It has ~15 dependencies.

I recently learned that large companies have entire processes for screening npm packages before they're allowed in production: security teams, private registries, approval workflows. I had no idea this existed when I built this.

Now I'm in a situation where I probably need to go through that process, but I'm a kid with no formal role in IT, no contacts there, and no idea how to even start that conversation.

Has anyone navigated something like this? Do I just... email someone? Is there a way to frame this that doesn't end with my tool getting shut down or me getting in trouble?

we went through a reorg and the team that owned our base docker image got folded into another team. nobody picked up ownership.

found out during an incident review that 12 services depend on that image. most are pinned to old digests and haven't been updated in months.

the image still builds in CI but nobody is maintaining it. no patches, no reviews. now a CVE hit the base layer  all 12 services are carrying the vulnerable package. still working out actual exposure: presence in the image doesn't automatically mean exploitable. depends on whether the vulnerable component is reachable from the network, whether there's a known exploit, and whether our runtime controls mitigate it. compliance wants everything remediated regardless, but the security team is trying to triage actual risk while we sort out ownership.

fixing it means patching the base image and getting every dependent service rebuilt and redeployed but ownership is unclear across those services too. some teams don't exist anymore and not everything is reproducible cleanly.

did you centralize base image ownership or handle it team by team? 

Over 25% of production mcp implementations are running on hardcoded static api keys per a 2026 security report. Not a surprising stat once you see how mcp actually gets deployed, the quickstart docs optimize for getting something running locally and most teams carry that auth pattern straight into production without revisiting it.

Our setup runs Gravitee as the enforcement layer in front of the mcp servers, which made the gaps in other architectures obvious when reviewing them: no iam binding on agent credentials, flat invocation rate limits that treat all tools as equivalent, audit logs that record a call happened but not which agent made it or what the tool returned.

The mcp server security baseline that production actually requires: oauth authentication with credentials tied to your existing iam rather than standalone static tokens, per-tool rate limits weighted by what that tool costs or risks if abused (an execute-code tool and a read-username tool are not the same risk profile), caller-identity logging on every invocation, and mcp servers inside your iam governance rather than operating as an exception to it.

Only 23% of orgs have integrated their existing iam as the authorization server for mcp infrastructure per the same report. Retrofitting it after deployment means touching every agent connection individually. Configuring it at the gateway layer from the start is a one-time setup.

We moved a government client project to Iron Bank assuming the DoD's official hardened repo would ship near zero CVEs. Ran them through Grype, got average 110 CVEs per image, 8 of them high or critical. These are the images the military considers secure enough for deployment. they're better than raw Docker Hub but hardened apparently just means someone reviewed the Dockerfile and called it a day. The gap between what the label promises and what the scanner actually finds is exhausting

i run compliance reporting for a mid-size fintech and this week completely wrecked whatever confidence i still had in our dashboards.

leadership wanted a simple exposure report before a quarterly review. just “internet-facing critical risk by business impact.” sounded straightforward enough.

ended up spending almost three days trying to figure out whether half the assets in the report were even the same systems.

we're not a massive shop. qualys covers most of the legacy/on-prem stuff, defender handles a lot of the cloud findings, a couple teams built their own aws config checks over the years and now everything dumps into different reports with different naming conventions and ownership mappings nobody fully trusts anymore.

same EC2 workloads showing up under old hostnames because autoscaling recycled instances. one tool tracks assets by private IP, another by DNS, CMDB still tied to org structures from before an acquisition last year. remediation tickets were routing into a ServiceNow assignment group that literally had no active members left in it and nobody noticed until tickets started breaching SLA.

worst part wasnt even the messy data. it was presenting numbers i knew probably werent right.

first pass spat out something like 340 critical finding instances on stuff we'd labeled internet-facing. but once i started drilling in, a big chunk of that was the same handful of assets getting counted 3-4 times across qualys, defender and our own aws config checks. real number of unique vulnerable assets was probably closer to 80-90, and even that i couldnt fully defend because half the hostnames didnt line up between tools. so leadership got a number i didnt actually trust, which is worse than not having one. 

then somebody asked for product-line breakdowns and i had to explain that our asset inventory doesnt even map cleanly to the current org structure anymore after the acquisition.

we drilled into one app that looked “high exposure” in the dashboard and half the findings were tied to old images nobody had deployed in weeks. another chunk belonged to systems ops had already wrapped compensating controls around but that context lived in ServiceNow notes instead of anywhere the reporting layer could actually see.

starting to feel like exposure reporting is mostly an asset reconciliation problem pretending to be a vulnerability problem. how people are handling identifier reconciliation once cloud churn, acquisitions and overlapping scanners start wrecking inventory consistency.

Hi!

I've worked in a few small-to-mid tech positions over the years (dev, tech PM, engineering manager, etc.), and one thing keeps coming back: building a technical remediation roadmap is painful. Either you do it manually (I spent 3 days checking EOL dates and CVEs once in a previous job, listing everything in a spreadsheet, this is what gave me the original idea), or you duct-tape a bunch of OSS tools together and hope it works.

I also watched my current company go through the ISO 27001 certification. We struggled on the EOL + CVE monitoring side (providing proof of the monitoring + actually prioritizing the info we got from it). Most tools on the market felt too heavy, too expensive, or assumed a security team we didn't have.

So I started building something for that gap: drop your SBOM in, get back a prioritized remediation roadmap (EOL urgency + CVE severity weighted with EPSS and CISA KEV signals, so you don't drown in noise). SBOM-upload first, optionally hooked into CI for periodic scans. Aimed at teams of ~10-50 people without a dedicated AppSec function.

Before I keep building, I want a honest feedback from people who would actually use this:

• Does this match a real pain you have, or do you already have a workflow that handles it? Or have I had unlucky experience?
• If you're on a small-ish team, are existing tools (Dependency-Track, Snyk, Aikido, Dependabot) too much for you, just right, or too little?
• What would make you trust a tool like this enough to upload your SBOM into it?

I'm trying to figure out if I'm building for a real market or just scratching my own itch. I'm happy to DM with anyone who wants to look at what I've got and tear it apart.

(Mods, I am happy to remove the post if this crosses the line of commercial advertising, my intention is genuinely discovering, not advertising)

PANW spent years telling anyone who'd listen that agent based was the only real way to do cloud security, that anything agentless was shallow visibility and marketing fluff.

Fast forward to Cortex Cloud 2.1 and what do they ship agentless Kubernetes scanning. AWS only for now, but still.

You cant build a decade of messaging around preaching agents are mandatory then quietly roll out agentless and pretend its a natural evolution instead of an architectural admission.

Kinda makes you wonder if the platforms that have been agentless first since day one were right the whole time and the agents are the only way crowd was just selling the architecture they had, not the architecture that works.

spent months building guardrails for our models. prompt filters, jailbreak detection, some fine-tuning on top. looked solid in testing then we ran red teaming and things started slipping through faster than expected. small variations in phrasing were enough to bypass controls that seemed reliable before.

after tightening things up, we ended up with a different problem. more false positives, legitimate queries getting blocked, and overall worse user experience. it feels like we’re trading one failure mode for another.

rn it’s not very clear what a stable setup should even look like. the more we lock things down, the less useful the system becomes. but leaving it loose obviously isn’t an option either.trying to find a balance between control and usability without constantly reacting to new bypasses.

how others adjusted their guardrails after red teaming exposed these gaps?

pnpm 11 feels like the first Node.js package manager update in a while that actually improves supply chain security by default.

Features like:

• minimumReleaseAge
• blockExoticSubdeps
• allowBuilds

directly reduce the risk of malicious package installs in CI/CD pipelines.

I wrote a short deep dive on why I think pnpm is now a better default than npm for production workloads.

Curious what others here are using in production today.

https://blog.prateekjain.dev/you-should-move-to-pnpm-from-npm-now-6e84b6cc7778?sk=fe3913487a067decbc069234e4e2ad1f

Our SRE team spent three months hardening the deployment pipeline last year. Locked down every step: signed commits, SLSA builds, runtime policies, all of it.

Then audit season came and the risk team asked one question that unraveled everything where do your base images come from?Well, the answer was docker hub. Then we sat there realizing we'd never once scrutinized the single biggest supplier in our entire software supply chain. The images ship unsigned with no SBOM or provenance just blind trust.

The pipeline was hardened, the front door was steel and the back door was docker pull. And we'd built the whole thing that way for years without once calling it what it is: an unaudited third-party dependency sitting inside the trust boundary.

After trivy, liteLLM, tj-actions, all of it, figured this was worth putting out there. If you haven't asked where your base images actually come from, ask before your auditor does.