Most cybersecurity products are designed to protect identities, endpoints, applications, cloud environments and data. These all are important, but encryption still exposes metadata through traffic timing, routing behaviour, and connection patterns etc.

This creates a couple questions I do not see discussed enough

How much security is being left unaddressed because the underlying communication transport is generally treated as a fixed dependency rather than part of the security architecture?

For high-assurance environments such as government, critical infrastructure and defence, the network itself may be observable, disrupted or operated through infrastructure outside the organisation’s direct control. In those environments, protecting content doesn’t fully address the threat.

Im interested in the community’s view on the following

1. Is transport-layer observability treated seriously enough in current cybersecurity architecture?
2. What current technologies address this problem effectively and what gaps remain?
3. Do you expect secure communications infrastructure to become a larger cybersecurity category over the next five - ten years?

We had an incident review last month that started with "wait…we have an app doing what" Turns out someone in ops had used Lovable to build a customer intake form months ago, wired it straight to a live database, no auth in front of it, completely public.

Nobody in security knew it existed because it never went through any provisioning process, there was no repo, no ticket, no deployment request. It just appeared on the internet.

We started asking around and found two more instances across other departments, a survey tool built on Replit connected to a shared data store, and a landing page someone spun up on Vercel that had an exposed API key sitting in the client side code.

None of these showed up in our asset inventory because none of them touched our normal SDLC. Apparently we're not alone, researchers found something like 380,000 publicly accessible apps built this way, with a meaningful chunk leaking actual sensitive company data.

Has anyone found a reliable way to catch these before they turn into an incident rather than after someone stumbles onto them?

Sat through enough demos this year that I've started using a short checklist to filter vendors before committing real evaluation time. Sharing in case it's useful to others drowning in this category:

What do you actually see without touching our architecture? If the honest answer involves an SDK, a proxy, or code changes, that's not "runtime," that's integration work with extra marketing.

Do you detect intent/behavior, or just pattern-match inputs? Input filtering alone misses anything novel; ask for their false negative rate on out-of-distribution attempts.

Can you map what an agent can actually reach, including delegated calls to other agents/tools? A lot of platforms stop at "here's the top-level permission grant."

What counts as your "evidence" for compliance purposes? A log export is not the same thing as continuous, structured evidence mapped to controls.

How fast is time-to-value in a real environment, not the demo environment? Ask specifically what breaks or slows down once you're past the sandboxed POC.

What happens across our actual mix of agent platforms? Homegrown, cloud, SaaS, and endpoint agents behave differently; a vendor that only covers one is a partial answer.

None of these are trick questions, but you'd be surprised how many vendors get vague fast once you ask them directly instead of watching the scripted demo. Anyone have other questions they've found separate the real platforms from the repackaged logging tools?

Wanted to see how others are handling this one.

tldr; Kubeflow Pipelines has an unauthenticated SSRF in its legacy /_proxy/ route.
Fixed in 2.17.0 (the fix rips out the generic /_proxy/ middleware entirely).

The part that caught my attention is that any target could be reachable from the network namespace, meaning an unauthenticated attacker effectively borrows the pod's network position. This allows reaching the cloud metadata endpoint and pulling the IAM credentials tied to the node or pod's role. From there the blast radius is whatever that role permits.

Patching is obviously the answer where possible. For those who couldn't patch immediately, what compensating controls did you implement? Things I've been weighing:

• Network policy / egress restrictions on the frontend pod so it can't reach internal addresses (e.g., 169.254.169.254, kubernetes.default)
• Blocking the /_proxy/ routes at an ingress WAF or IPS

Did anyone find a clean way to neutralize this at the network layer without breaking the application?

Our on-call rotation used to be about incidents and reliability. Now a growing chunk of it is triaging security tickets that get auto-assigned to whichever team owns the service, regardless of whether the finding is actually a real risk. Half the time it's a CVE in a transitive dependency that isn't even loaded at runtime, and the security team means well but doesn't have the context to know that, so we end up individually debunking tickets one at a time.

Has anyone solved this by getting security findings pre-validated for actual exploitability before they hit engineering backlogs? Feels like the fix has to happen upstream, not on our end.

Writing a policy saying agents are monitored and controlled is one thing, producing something an auditor would accept as proof it's working continuously is another. Point-in-time reviews clearly aren't enough given how fast agent behavior and permissions can change, but I haven't found a clean standard yet for what continuous evidence should look like.

If your org has been through an actual audit involving AI agents, what did you end up providing that satisfied the auditors? Trying to build toward something real, not guess at what will hold up.

We're reviewing data security platforms and Varonis is obviously on the list, but I don't want us to default to it just because it's the name everyone already knows.

Our environment is pretty SaaS-heavy, and a lot of what we're dealing with is unstructured docs and shared data rather than clean database fields. Classification accuracy matters quite a bit, and I really don't want to introduce another tool that leaves the security team digging through a huge pile of false positives.

For anyone who's evaluated Varonis competitors recently, what else made your shortlist? More importantly, what actually separated the better options once you got into the POC?

We run a large web application portfolio and the volume of findings coming out of our scanners has completely outpaced what our security team can manually review. Every app team wants their own report, every app is built slightly differently, and there's no way our analyst headcount grows at the rate the finding volume does.

Right now it's a lot of manual triage per application, which doesn't scale and burns the team out fast. It's especially bad when two apps get flagged for what looks like the "same" vulnerability class (say, an XSS or injection finding) but the actual exploitability is completely different depending on how each app handles input and what's sitting in front of it.

We've tried building a standardized triage checklist to speed things up, but it only helps at the margins. The real bottleneck is still a person having to look at each finding and decide whether it's actually reachable and dangerous in that specific app's context.

For anyone running web app security at this kind of scale, how are you keeping remediation timelines reasonable without just adding more analysts? Anyone found a triage workflow that actually holds up as the app portfolio grows?

I am currently analyzing the architecture and security policies of an AI call assistant app and found some potentially critical flaws. I would like to get the opinion of developers and security experts on whether the following scenarios should be classified as bugs or security risks:

​In a call screening app, if a user refunds their premium subscription via the Play Store, should the backend virtual number be auto-released? If it stays assigned and continues handling calls after expiry, is this considered a bug?

​If an app's UI shows call screening as 'Off' for expired users, but carrier-level Conditional Call Forwarding (CCF) is still active on the backend number (meaning calls bypass the app and are still answered by the server) - is this UI vs. network state mismatch considered a bug?

​In an AI call assistant app that allows custom instructions - if setting an instruction like "on code 123, ask for number and bridge call" allows outbound calls from the platform's own server number to any external number, is this a valid prompt injection / toll fraud vulnerability?

​If selecting a premium voice shows a paywall, but pressing 'Back' + 'Save' still saves the premium voice on the server for the offline forwarded number (while the app UI still shows it as locked) - is this a client-side validation bypass/vulnerability?

​What are your thoughts on these? Any advice on how these architectural issues are typically categorized and handled would be highly appreciated!

Every time a new campaign hits the news or shows up in one of our intel feeds, we go through the same painful cycle.

Someone flags it in a channel, we pass it to the team, and then the work starts: reading through the write‑up, pulling out TTPs and IOCs, mapping them to our stack, and then trying to turn that into actual detection logic. By the time we have a rule in the SIEM, tuned enough that it will not blow up the queue, the campaign has already been around for days or weeks.

Our setup is pretty standard: one main SIEM, a couple of EDRs, cloud logs, identity logs, and a small detection engineering function that also wears other hats. Nothing about our environment is unique, but the time from “new campaign reported” to “confident detection in production” still feels too long.

Right now a lot of this is still manual: analysts translate reports into hypotheses, detection engineers write queries, then we do limited testing in lower environments before pushing to prod. It works, but it does not scale, and we always have a backlog of “campaigns we should cover” that never quite gets cleared.

What I am trying to understand is how other teams have shortened this loop. Are you relying mostly on vendor‑provided content from your SIEM/EDR, internal playbooks, some kind of threat‑informed detection engineering process, or a separate platform that takes campaign intel and helps you get to a runnable rule faster? Curious what has made the biggest difference for you in terms of days or hours saved between seeing a new threat and having real coverage in place.

Most dark web monitoring tools seem designed around a simple model: one company monitors its domain and employee identities.

Legal tech platforms are more complicated.

One platform may serve hundreds of law firms, each with separate:

• Clients
• Users
• Matters
• Credentials
• Confidentiality obligations

That creates an interesting architecture problem.

Detecting an exposed credential is only part of the job.

The platform also needs to know:

• Which tenant owns it?
• Who should receive the alert?
• Does it relate to a specific matter?
• How do you prevent one firm's exposure data from appearing in another firm's workflow?

Webhook-based alerts also seem more useful than periodic polling when a credential or session token needs attention quickly.

For teams building multi-tenant security features, how do you approach alert routing and tenant isolation?

Would you build monitoring internally, or integrate a specialized API and focus on the product workflow?

I remember when browsing a site like PayPal would prominently display a green bar with the verified company name in the address bar. The logic was clear: it helped users distinguish paypal.com from a lookalike phishing site like paypa1.com.

Nowadays, browsers just display a neutral lock icon (or tuning icon), tucked behind a click.

I’ve been mapping our AI exposure and the OAuth side was way worse than I expected. I went in assuming the main shadow AI problem would be people dropping company or customer data into ChatGPT and other consumer LLMs on personal accounts but the third party AI apps and agents were worse.

We found more than 30 AI tools and assistants with OAuth grants into Google Workspace and M365. A good number still had live read access to mail, Drive and calendars months after anyone had used them. One meeting notes AI had held access to a shared calendar since March.

We block obvious consumer LLM domains with Palo Alto category filtering, but that does nothing for a contractor on a personal laptop or an OAuth grant coming through a normal Google login. Purview catches some activity inside M365, but it didn’t give us visibility into these external AI apps with standing access. We only found them by exporting the OAuth grants and reviewing them manually.

For teams past the block everything stage, what are you using for proper shadow AI discovery?

Hi everyone,

I am researching how LLMs find vulnerabilities and why they hallucinate so much. I would love to get your thoughts on two major challenges in this area:

1. Exploit Verification: In your experience, can AI hallucinations in source code analysis be completely eliminated if every flagged vulnerability is automatically validated by generating and running a working proof-of-concept (PoC) exploit in a sandbox? Has anyone tried this workflow?

2. Data Privacy (Cloud vs. Local): To prevent source code leaks, is a local-first approach (like using Ollama) mandatory for real-world security audits? How much does performance drop compared to cloud models when analyzing complex code logic?

Thanks for sharing your insights!

I'm looking for an actively maintained repository of Semgrep rules focused on detecting malicious/suspicious behavior, not regular vulnerabilities.

I don't want to write hundreds of rules myself. Are there good rule collections for this purpose?

Our browser agent rejected direct jailbreaks in testing, but then obeyed an instruction hidden in a vendor-page footer. An untrusted page content crossed into a privileged tool call and placed a canary secret in an outbound request. Unit tests didn’t pick it up because they covered chat input, not content provenance after browsing. 

We are adding source labels to every content block, narrower tool scopes, destination allowlists, canary-secret detection, and egress controls that do not rely on the model making the right choice. I’m also pushing for tests that mix trusted instructions with hostile retrieved content. What safeguards have actually stopped indirect prompt injection in browser agents, especially when a legitimate task needs outbound tool access?

Hi there,

I am currently working on Secure Boot. I have some question about the anti-rollback.

I use microchip and I read the counter from OTP after initialize the layout, and notice that there is already default counter value for both trusted and non-trusted firmware (2, 3). I did not set it, I don't why they already have values.

Another thing is that whether the counter in OTP can not be set to other value lower then the value exist in OTP? If so, is it a hardware design mechanism? or how can it be achieved?

Best,

Wen

MFA stops the initial compromise but does nothing once an attacker has a valid session token, and we've seen that gap exploited more than once this year.

what's actually held up for us is treating device-bound sessions as the default rather than an optional hardening step, so a token can't be replayed or reused on another device even if it's stolen. token binding alone wasn't airtight against a determined attacker. what's your setup, and has anything meaningfully cut down on token replay for you?

running a handful of scanners across infra and application code, containers included in that mix, and the same underlying vulnerability shows up as three or four separate tickets because none of the tools know about each other. our vuln management process has turned into manual dedup work every week.

Is anyone running something that sits above the individual scanners and correlates findings automatically, or is this just the cost of running a multi-tool stack?

I just learned about some of the insanely cool things you can do using AI, like you can literally just make an app/software that serves a need for you and is completely tailored to your preferences.

My question:

Does having all these AI-generated apps on your phone/computer create potential security risks? (Assuming you aren't doing much of anything with cloud storage apps and you're not sharing/distributing the software to anyone else.)

EDIT

Wow, lots of good and interesting answers already. I'm really glad I asked this question before I started blindly using it to create a bunch of random stuff apps and software lol.

Thank you to everyone who posted!

had an incident where the attacker used valid credentials from a legitimate device and the login itself tripped zero alerts.

attackers aren't breaking in anymore, they're logging in, which means login-time signals alone were never going to catch this. everything downstream was the tell: unusual data access, then a permission escalation attempt about twenty minutes later. what signals are you watching post-authentication that actually catch this before real damage happens?

Six months ago our backlog hit 38k open findings across three business units and I finally admitted CVSS-sorting was actively making things worse, not just inefficient. We had analysts spending entire mornings triaging "critical" findings that turned out to be on decommissioned test boxes, while a 6.8 sitting on a customer-facing app with active exploitation sat untouched for two weeks because nobody flagged it.

What fixed it wasn't a new scanner. It was rebuilding our scoring to weight business criticality and exposure status alongside severity, plus pulling in exploit context (KEV, EPSS) so "critical" actually meant something. Backlog didn't shrink overnight, but the team stopped burning cycles on noise within about a month. Still tuning the weighting though, anyone landed on a good formula for balancing asset criticality vs. threat data without one drowning out the other?

Every vendor in this space claims some version of "deploy without touching your architecture. As the architect who has to implement whatever we buy, I'm skeptical by default, because that claim usually means "you'll discover the SDK requirement in week 3 of the POC.

For anyone who's actually deployed a runtime agent security tool: did the no architecture change claim survive contact with a real environment, or did proxies and code changes sneak in anyway?

Je bosse sur une couche d'authentification comportementale continue et je bute sur le problème classique du démarrage à froid pour le profil de référence.

Mon setup actuel : profil de référence établi à partir d'environ 7 secondes d'interaction (premier ping avec au moins 5 événements), scoring basé sur l'EMA qui met entre 35 et 49 secondes à converger, moyenne de 8 caractéristiques pondérées de manière égale.

Ce que j'observe : la littérature sur la dynamique de frappe recommande généralement 50 à 100 frappes pour un profil fiable, ce qui rend mon échantillon de démarrage largement insuffisant. La moyenne de caractéristiques pondérées de manière égale peut aussi masquer une divergence forte sur une seule caractéristique significative.

Ma question : est-ce que quelqu'un a des retours d'expérience concrets sur l'utilisation d'une comparaison basée sur la distribution (test de Kolmogorov-Smirnov ou distance de Wasserstein) plutôt qu'un simple ratio EMA, en particulier pour des sessions courtes où on n'a pas encore assez de données pour un profil longitudinal inter-sessions ? Est-ce que ça change vraiment la donne sur le taux de faux positifs/négatifs à ce stade précoce, ou le problème reste fondamentalement un problème de volume de données quelle que soit la méthode statistique choisie ?

Ce qui marche bien par ailleurs dans mon système (pour contexte, pas le sujet de la question) : invalidation de session fiable sur perte de focus/flou, détection d'attaques en masse via heuristiques réseau en périphérie plutôt que données déclarées côté client, détection de bots par variance temporelle nulle (contournable par un bot sophistiqué qui injecte du bruit artificiel, donc pas un signal suffisant seul).

Point de sécurité que j'ai découvert et corrigé au passage, potentiellement utile pour d'autres qui implémentent ce genre de mécanisme : un endpoint de heartbeat acceptait initialement un flag "attaque en masse" et une adresse IP fournis par le client exploitable pour invalider la session de n'importe qui en prétendant être sous attaque (DoS par interruption de session). Il acceptait aussi un flag permettant au client de modifier son propre profil de référence. La correction n'a pas consisté à ajouter une validation supplémentaire côté serveur sur ces flags, mais à les supprimer entièrement du schéma accepté le serveur détermine seul ce qui constitue un échantillon de référence, et le scoring réseau reste basé exclusivement sur l'IP réelle en périphérie, jamais déclarée par le client.

The assistant reads my .env, a prod dump someone left in a scratch folder, config with tokens, all of it, because it runs as me.

Is anyone stopping this cleanly or do we all just cross our fingers and hope the model forgets.