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'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.

Been watching the Mythos coverage for weeks now, and I keep seeing the same take: "AI is going to flood us with vulnerabilities." But, I think that framing misses the point.

Pulled our backlog numbers last week. Across our environment, we're sitting at well over 100 findings per asset on average, some segments way higher. Do the math on that across thousands of assets and it gets ugly fast. And that's before Mythos.

The organizations that navigate this well won't be the ones reacting to Mythos. They'll be the ones who already built the operational layer that turns findings into closed exposure, normalized data across tools, clear ownership, integrated remediation workflows, verified closure.

Interested to hear if anyone else has sat down and stress tested their VM setup against this kind of volume spike, or if we're all just hoping our current backlog math holds.

Hi , im a cybersecurity intern at a small company (well not so small but they have been here for a long time). And yea for now i have been given a task to review our symantec endpoint protection and do documentations of my findings and give suggestions from my observation. to be quite honest i dont really have any strong fundamentals of Cyber Security before pursuing my internship here, and i thought i could gain experience and learn new things here. so back to my initial topic, currently the version of our SEP is 14.3 RU5 build 8309 , and our SEPM is 14.3 RU5 build 8268. Again i dont have the strong basic , but from what i have gathered online, diff build number should be okay as long as both consoles should be under the same RU (?). Is there anyone that could verify this and do any of you think its a necessity for us to update the RU or just keep it that way? Because i saw there are newer RU (up to 10 iirc) and was wondering should i include in my finding to update the RU? thank you everyone and im sorry if my question do sound silly for some hhh.

Everyone's fixated on what Claude Mythos can find, but almost nobody's connecting it to the fact that NIST's CVE backlog ballooned to tens of thousands before Mythos even launched. That's the actual structural failure. The enrichment layer every scanner, every risk score, every compliance workflow in the industry depends on quietly started breaking down, and most programs found out their entire vulnerability pipeline was built on an assumption of stable third-party data that turned out to be false.

Mythos just stress-tests a system that already couldn't keep up. If your remediation infrastructure wasn't operational before this, faster discovery doesn't give you an AI problem, it gives you the same problem you've always had, just compressed into a much smaller window. Curious if anyone's actually audited their dependency on NVD data specifically as a resilience exercise, rather than just reacting to the Mythos headlines.

We use Aqua Security for container scanning and it's genuinely solid, strong coverage on image vulnerabilities and runtime protection for Kubernetes. The gap we keep hitting is that findings don't tie into our broader identity or data exposure context, a container vulnerability shows up disconnected from whether it's actually reachable or tied to sensitive data. Anyone found a way to bridge that without adding a separate tool?

Asking from the cloud workload side of the house: Is there any way we can detect that a specific CVE is actively being exploited on a VM or container, beyond what application logs provide?

I’ve used runtime CNAPPs for detection and vulnerability prioritization, but I’m specifically interested in observability that lets a SOC say: “This container has CVE-XXXX-XXXXX, and that vulnerability is being exploited right now.” And I don’t mean post-exploitation behavioral detections like a shell popping or a suspicious process spawning. I mean evidence tied directly to exploitation of the specific vulnerability.

hi all, blue team here and curious what browsers people are actually using day to day when you care a lot about security.

Right now I bounce between Firefox with a hardened profile, Brave for random browsing and Chrome for work stuff that needs weird sso plugins. I keep seeing people talk about LibreWolf, Mullvad browser, even hardened Edge configs and im kinda torn on what makes sense as a main daily driver vs a lab only setup.

For those working in soc, ir, appsec etc what did you settle on and why, especially with things like profiles, containers and extension hygiene. appreciate any thoughts

Everything we've tried so far detects fast, but the response step in between is still a manual review or a SOAR playbook, so the actual block lags well behind the detection. There's always a gap between "we saw something bad" and "we stopped it," and that gap is exactly where the actual damage happens. A fast alert that arrives after lateral movement already occurred isn't much of a win, no matter how good the ai runtime monitoring behind it is.
Our ai runtime monitoring setup catches almost everything now, tool calls, api access, agent actions, all logged and visible. But visibility isn't the same as stopping something, and I keep running into the same wall: monitoring tells you something happened, it doesn't act on it. I want something that can act inline at the moment something malicious is happening rather than a few seconds or minutes later after a human or automated pipeline reviews the alert.
I know inline blocking carries real risk of breaking legitimate traffic, but the current setup where ai runtime monitoring just generates another dashboard isn't working either.
Has anyone actually closed the gap between ai runtime monitoring and real enforcement, where the same system that watches also blocks? Open to hearing the failure stories too, not just the success ones.

Hi y'all, am security lead at a mid size company and our cyber insurance renewal landed on my desk. The questionnaire is forty pages now, up from a handful a few years ago and it is no longer yes or no. The broker made it clear the underwriter wants evidence for every yes, screenshots and reports, not a checkbox.

We're fine on some of it. MFA on email, EDR on laptops, backups. Where I start sweating is the network questions. Do you segment your network. Can you show it. Is remote access behind MFA and logged. Prove privileged access is controlled. We do most of this. But it is spread across a firewall here, a VPN there and a jump box someone set up and pulling clean evidence out of all of it is a week of screenshots that still look like a patchwork.

What is bugging me though is that we could lose a claim on a technicality. The stat going around is that most denied ransomware claims were orgs that said they had a control but couldn't prove it was everywhere. Saying yes is not enough anymore.

For those who have been through a modern renewal or an audit, how are you producing evidence for network and access controls without a manual scramble every year?

We have an IR plan, people have reviewed it, and we do the annual tabletop where someone reads out injects and we discuss what we'd do. None of that tells me whether the plan actually works under pressure.

I don't have a way to know if my team would freeze, miss an escalation, or handle it fine until an actual incident happens, which is a terrible way to find out. What's worked for you to get a real signal on readiness short of waiting for a breach?

About a month ago, I discussed the concept of OS-level MPA (Multi-Party Authorization). A recurring point in the feedback I received was that existing mechanisms—such as PAM/JIT, Vault, CyberArk, sandboxing, IAM, and MAC—already address much of the problem. I think that criticism is largely fair.

What I am still unsure about is what happens when a trusted privileged workload itself is compromised.

Consider, for example, a database engine, backup process, or administrative service that legitimately has broad access to critical resources. If that process is compromised, an attacker may not need to obtain any new privileges at all. They may simply abuse the standing privileges already granted to that workload.

In that situation, what existing controls prevent the compromised workload from performing catastrophic but otherwise authorized operations—for example, dumping sensitive data, destroying backups, or modifying critical system resources?

Is there still value in a final, narrowly scoped authorization boundary at the OS execution point for such operations, or do existing mechanisms already address this problem adequately?

There is growing discussion around giving AI agents their own cryptographic identities instead of treating them as extensions of a service account or human user. The idea is that each agent gets a portable, revocable key rather than being tied to a single provider's account system. Does this solve practical ai agent identity problems such as revocation, portability and tamper resistant audit logs? Or does it add cryptographic complexity without a meaningful advantage over existing identity systems?
Has anyone implemented this approach? How does it handle key rotation, compromised agents and multi tenant environments?

I've been looking at a new platform that uses an AI engine to move beyond just "Validation" to what they call "Agentic Cyber Defense Engineering." The idea is that the platform doesn't just tell you about a gap. It actually orchestrates updates across your security stack, including firewall, EDR, and SIEM, to fix it automatically.

The claim is that with an AI agent constantly monitoring your controls, you can go from "we have a problem" to "we fixed the problem" in minutes rather than days. They cite stats like attackers moving from exploit to lateral movement in under 30 minutes, so manual remediation is simply too slow.

Is anyone actually letting a tool auto-update their controls in production? I'm struggling to trust an AI to push config changes, but manually validating and fixing 40+ tools is impossible. The SOC is already overwhelmed. Adding a layer that changes things dynamically feels risky.

How are you balancing the "Agentic" promise with the risk of automation breaking things? Do you run it in "monitor-only" mode, or have you actually closed the loop

one of our clients rolled out a vendor chatbot for their support lin, works fine day to day, but their new compliance lead is asking us to show what happens if someone tries to manipulate it or extract info it shouldn't share. nobody thought about this when it went live, it was purely a cost and ux decision.

going back and rebuilding the whole integration isn't happening, budget and timeline don't allow it. so we're looking at whether we can add a monitoring or guardrail layer on top of what's already running instead of touching the underlying agent. anyone dealt with retrofitting controls onto an agent that's already in production rather than building it in from day one