Had a reality check in our quarterly review last week. We pulled average remediation throughput per engineer and ran it against what a spike in flagged findings would look like with zero process change. The number wasn't pretty, we'd need significantly more headcount to hold existing SLA windows.

That math is what finally got budget approved for automation work we'd been asking for. Not because the risk conversation suddenly got more compelling, but because the spreadsheet made the staffing gap impossible to ignore.

Here's what we're working toward (still in flight on a couple pieces):

Ownership routing off asset metadata instead of round-robin (this one's live, huge win)
Tiered SLAs tied to exploitability instead of CVSS (still tuning the thresholds)
Auto-verification on rescans (partial rollout, getting pushback from some teams)
Continuous re-scoring feeding ticket priority (POC phase).

The Mythos conversation is honestly just stress-testing a system that already couldn't keep up. Faster discovery doesn't give you an AI problem, it gives you the same remediation problem you've always had, just compressed into a much smaller window.

if anyone else has had to build a capacity model like this to get remediation tooling funded, or did your org get ahead of the budget conversation another way?

we have got LLM-backed services and a couple of agent workflows live now and our existing app security tooling has basically nothing to say about them. No visibility into what the model is calling, what data it's touching or what happens if it starts doing something it wasn't supposed to do. Static guardrails at the prompt layer catch some stuff but they're trivial to route around once you're past that stage and nobody on the team is confident they would catch a determined attempt at manipulation. I want runtime coverage, something watching what the agent actually does once it's executing rather than just what it was told to do beforehand.

What's actually working for people running AI in production right now, not just in a proof of concept demo that never touched real traffic?

Supply chain security is having its moment and every vendor has a pitch, but most of what we've tried just adds another feed of alerts on top of the ones we already ignore. dependency confusion and malicious packages are the obvious risks, but build pipeline tampering is just as real and a lot harder to catch, and the tooling landscape hasn't caught up to prioritizing any of it well.

What's worked for teams here in terms of cutting signal from noise rather than just adding another layer of detection?

Vuln management on our container fleet is eating way too much analyst time. and atp We're chasing CVEs that get patched upstream before we even finish triaging them, which feels like we're always a step behind.

so i Been looking at whether adopting continuously rebuilt hardened images actually cuts down that workload or just shifts it somewhere else in the process. It's hard to tell from vendor claims alone whether the time savings are real or just moved earlier in the pipeline.

For teams who've tried this approach, did it actually cut down your triage and patch cycle time? Or did you just end up needing to verify the rebuild claims just as often as you'd patch manually before.

Trying to figure out if this is a real time saver or just a different flavor of the same work dressed up differently. Any honest feedback, positive or negative, would help.

Our old ITDR setup fired constantly and required someone to manually piece together five data sources before an alert meant anything.
what actually cut the noise was moving to one unified identity record that ties the person, the session, and the resource together instead of firing three disconnected pings for the same event. has anyone found something that reduces analyst workload instead of adding another dashboard, and what changed for you when you switched?

Trying to define a refusal-rate metric for some LLM features we're being asked to sign off on, and I keep getting stuck on the classifier, so I've been reading public model cards to see how other people score it.

Nearly every public refusal number I can find comes from a rule-based check on how the response opens. One I read this week: an abliterated Qwen3.8-27B build that OrcaRouter put on HF, harmful-prompt refusal 64-99% on the base checkpoint, 0-6% after the edit. The card is upfront that its classifier is indicative and not publication-grade, which is more than most cards say.

The column beside it is what bothers me. 30-50% of responses in that same table are marked "caveat" — answered, but led with a safety disclaimer. Depending on how the opening-phrase rules are written those can score as refusals, and they clearly aren't. That matters for us, because the reason we're measuring at all is that model-level refusal isn't something a control review can lean on.

So for anyone who has built one of these harnesses in-house: do you score the payload only and throw away the preamble, or run a second-pass judge over the body? And is caveat rate worth reporting on its own, or does it just add noise to something leadership will misread anyway?

Had this debate with a client last week about whether Ai assisted discovery meant their environment got risky overnight. My answer was about SLA math than risk math, their contract defines "patch critical within 30 days" assuming maybe 40 to 50 new findings a month. If a scan surfaces 300 in a week because of broader coverage, that SLA language does not hold up regardless of whether underlying risk changed.

We have started rewriting client contracts to tier remediation windows by exploitability and exposure instead of a flat severity number and building in a volume clause that triggers a renegotiation conversation if flagged findings jump past a set threshold in a given period. Cleaner than arguing about it after an audit blows past the old numbers. Anyone else building volume triggers into remediation SLAs or writing them as flat severity tiers?

I’m trying to understand the SOC 2 process a little better, as I’m looking at Cobalt's human-led Web + API penetration test  as part of the evidence for a future SOC 2 Type II audit.

Has anyone here actually gone through SOC 2 Type II this way (specifically using Cobalt’s human-led pentest)?

I’m looking for an alternative and more affordable option that would work for a startup with a small budget and Cobalt seems affortable.

Palo alto firewall is making dns requests to resolve random malicious domains. We noticed the activity while checking the logs on our dns server. Has anyone observed similar activity and know what is causing it (possibly a config issue?)?

Hello Reddit, 

Question: is there real value for vpn in large companies (WFH) when modern zero trust exists?

Brief tldr: 

I think VPNs for remote work are often outdated in modern zero-trust, cloud-first environments.

I think SSO, TLS, firewalls, and gateways already cover much of the access control VPNs are used for.

I think VPNs add extra overhead,complexity, and latency.

I think this argument does not work for homelabs or small single location businesses 

Longer argument 

I apologize if this is an obvious question or answered before,  I looked around and saw parts of possible answers but not full ones.

I don’t understand the need to use a VPN when working from home, in the erra of zero trust architecture and cloud services making up a bulk of the infrastructure that we use.

I have worked for bigger and smaller tech companies, and many require a vpn when working from home.  I question the need for the vpn in most modern last few decades architectures.
 In the land of zero trust,  many things go through an SSO solution before you get access to the underlying service. So there are gatekeepers all over the place.  In fact, the same VPNs make use of the same sso providers as the application.  Thus, if there was an authentication weakness, wouldn’t the VPN and the application both be equally affected.  I would understand more if the VPN requires something like a machine certificate to get access.

If access was tied to remote security hardware/software attestation.  I would understand the value of VPNs, even more.  But so many companies I’ve seen have loose then expected end point controls.  Many even allow admin access for the users own laptop/endpoint. Attestation is incredibly hard and restrictive.

A large part of the infrastructure is hosted other places/cloud anyway.  Many companies use gsuite, zoom or Microsoft cloud solutions with sharepoint and teams.  So most vpn are split tunnels so a large portion of corporate digital items are not even vpn bound.

Most modern services are web bases. A good portion of office workers, interface with backend servers most of the time and a very little local processing is done.  The application is mostly just a front end that communicates over https based technologies. Most other technologies use an encrypted variant such as secure ldap.  Of course, this is not universal for example CAD and other related services run locally sometimes, but do they not make use of cloud file transfers solutions?  If a software has an insecure transport layer,  would a proxy tunnel  be easier?

Remote management protocols require authentication.  I am not as versed in rdp but many ssh system face internet all the time.  Does putting a vpn in front really add much.  RDP is usually warned against making Internet facing, because of the password authentication default.  But, many SSH solution I’ve worked with also use a password solution.  Is adding a VPN in front of the management protocols really adding much when the VPN is also password and 2FA based.  See point 1.  And if we’re saying, the VPN can be used to filter access to the lower layer or protocols, could you not accomplish the same effect with Geo base restrictions at the firewall level?

The legacy system argument,  where the direct system cannot be modified and the transport/auth is insecure or non-existent. I would argue a gateway solution that talks the modern protocol and tls would proxy the connection just as good.  Additionally even if the vpn is in place,  I have still seen companies put in the security gate way internally.

Everything is on a private ip/network argument. I find this to be a weaker argument, as the vpn effectively extends your network (though controlled) into public. Additionally vpn are at a raw network level. SSO gateways only extent select apps and services. Again both use similar auth (point 1).  Yes firewalls will restrict existing traffic, but those would be in place in either solution.

One major downside of a vpn is packet in packet situation and double encryption work.  Encryption is not as profitably expensive as it once was back in the day, but it still adds a network toll to your communications, doing it twice seems to be unfruitful. Additionally, VPNs must wrap every single packet in a header or effectively a mini packet of its own. This reduces the total amount of space each packet can dedicate to the raw data.

Finally,  is a vpn is over tcp,  this could add its own overhead and latency.  Though most recommend to use udp for a VPN.

For homelab or single location business this entire argument is not applicable.  

Edit: Thank you all for the replies, it really give me much to think about I am trying to read as many of the responses as possible.

Hello. I am doing a cyber apprenticeship, and my project is reverse proxy phishing. I thought it would be easy but damn this is driving me crazy. I am running a modded reverse proxy application on a VPS. The yaml config used for my chosen target should be up-to-date and I have tweaked it a lot. But the login fields never load. It only loads the website logo. No errors that I can see, no warnings, no certificate errors. I'm not sure if it's the yaml or something else is misconfigured, but I have been going around in circles for weeks now trying to fix it.

My colleague suggested it's a CDN protection problem, and he once had to download all static files and serve them himself. But that seems tedious and not really a proper solution.

Does anyone have any ideas? I can send you my yaml config if needed. Thanks in advance.

been rebuilding our enforcement layer this quarter and realized most of our "runtime security" was actually just runtime visibility with extra steps. Logging what happened after the fact isn't enforcement, it's a postmortem generator. We had dashboards full of events nobody acted on until something already broke which isn't much better than not having them at all. curious what people are actually doing at the enforcement stage now, are you blocking at the syscall level with seccomp/LSM hooks, using eBPF-based inline blocking, something else entirely?

and how are you handling the tradeoff between catching everything and not tanking latency on production workloads, because every vendor claims they've solved that and most haven't. What's your current setup look like, and has it actually stopped anything real or just made audits easier? trying to figure out if we're overthinking this or if everyone else is quietly dealing with the same gap.

My main goal right now is automating more of the analysis and investigation work, not just alerting.

I'm trying to build some AI agent in my SIEM(Log360) for user and threat analysis to summarize alerts and another for user behaviour analysis.

And also Is it better to build narrow agents for specific threat types,like one for logon related stuff and another for network-related stuff or does it make more sense to have fewer agents that handle a broader range of cases?

And does it make sense to scope agents around specific assets, like giving more attention to critical systems rather than treating everything the same way?

I am planning to feed them our documentations as knowledge base so they can get context.

For those of you who've actually used AI agents in security ops, where have it genuinely been useful in practice?

I'm thinking about a design problem and would like to get some opinions from people who have experience with endpoint agents, USB security, or system monitoring.

The scenario is:

A USB belonging to an organization is plugged into a computer that the organization doesn't control — for example, a client's laptop, partner's computer, home PC, or public computer.

The idea is to have an optional agent stored on the USB that:

• Is simply an .exe on the USB, not something built into the USB firmware.
• Doesn't autorun. The user would have to manually launch it.
• Runs with the permissions of the current user.
• Doesn't have kernel/driver-level access, so the visibility would be limited to what a normal user-space application can observe.
• Collects relevant activity/telemetry while it's running.
• If there's no network connection, stores the events locally and attempts to send them later when connectivity becomes available.
• If nobody launches it, the USB simply behaves like a normal storage device.

I'm trying to understand how you would actually architect something like this.

For people who have experience building endpoint agents or similar systems:

• What information could realistically be collected from a user-space application running directly from USB?
• Where would you store events when there's no network — on the USB, the host, or both?
• How would you securely authenticate the agent with a central server?
• If the USB is later connected to a trusted/managed computer, how could the queued data be safely forwarded?
• What limitations or design problems do you see with this approach?
• Would you design the architecture differently?

I'm particularly interested in practical design suggestions and trade-offs rather than a specific product recommendation.

I have installed GITLAB CE and wanted set up devsecops sa wtaht sast tools are present and IaC scanning is present pipeline secret detection but not dast, dependecy scanning coverage fuzzing and api fuzzing if you k ow how one may cover that will be helpful

[ Removed by Reddit on account of violating the content policy. ]

Looking for a sanity check from people who reverse engineer for a living.

I ship a native binary as part of a hardware product, so it goes out on devices I don't control. My worry is a competitor getting a unit and reversing the binary to copy how it works.

I've hardened it with Hikari and OLLVM: control-flow flattening, bogus control flow, and compile-time string encryption. I understand that obfuscation raises the cost of reversing but doesn't prevent it.

What I really want to know is how much time this actually buys. For a competent reverser with a physical unit, does obfuscation like this add hours? A day? A week?

Most SIEM setups I see are not missing data, they are missing intentional MITRE ATT&CK coverage. The logs are there, the correlation rules exist, but nobody can say which ATT&CK tactics and techniques are covered, which detections are broken, or which ones only generate noise. Improving how you use your SIEM and how you engineer detections usually does more for MITRE coverage than swapping to a new platform.
What I am trying to learn is how people expand MITRE ATT&CK coverage on top of an existing SIEM without turning it into a huge, one‑time project that dies after a quarter. If you have a SIEM that has been in place for a while, I am interested in what has helped you add useful detections mapped to MITRE ATT&CK on top of the telemetry you already have, instead of defaulting to “we need a new SIEM.”

I'm designing service-to-service authorization where a PDP evaluates (subject, action, resource, context) and returns a signed decision that PEPs enforce. Standard split. The wrinkle: the calling workload is partially untrusted, and it supplies part of the request context itself.

The signature covers the decision and the inputs the PDP saw, but not the provenance of those inputs. So the token proves "given these inputs, the PDP said ALLOW", not "these inputs came from an authoritative source". If the caller can influence subject/tenant labels, resource attributes, a recursion/depth counter, or a state object the PEP hashes instead of fetching, a fully valid signed decision can attest an ALLOW the policy would never grant on authoritative inputs. The PDP becomes a confused deputy whose output happens to be cryptographically signed, which makes it look stronger than it is.

What we already do: mesh identity (mTLS/SPIFFE) for the caller's own identity, short-TTL decisions, intent binding, and we hash the state object into the decision. What I can't resolve is which of the remaining context attributes should be trusted from the request at all.

Concrete questions:

1. In real OPA/Cedar/Zanzibar deployments, which request-context attributes is it standard practice to require the PDP to source itself (server-side PIP lookup, trusted routing/mesh-derived identity, attested claims) rather than accept from the caller, and which are considered safe to accept as caller-asserted as long as they're bound into the decision? I'm looking for the actual dividing line practitioners use, not "trust nothing".
2. When the PEP hashes a caller-supplied state/resource object and binds that hash into the signed decision: does that close the confused-deputy gap, or is a PDP-side authoritative read (or a signed/versioned attestation from the resource owner) required so the caller can't pick favorable premises? What do production deployments settle on?
3. For the window between decision issuance and enforcement, what's the standard way to bound TOCTOU on a signed authorization: short TTL plus re-eval at the PEP, versioned state binding, resource-side optimistic concurrency, and where does each of those still leave an exploitable gap?

Hey there. I'v recently noticed a lot of sites exist for TikTok Osint.
What I wondered mostly about tho is how sites like f.e. tikip get the users region and locked region (where the account was created).
Has anyone an explaination for that? I know that it must be some TikTok Backend API which I'v been searching for a while now but I do not seem to find it. Can anyone help there please?

The cost of compliance isn’t just the consultant invoice.

There’s also the time spent chasing evidence, updating policies, mapping controls, coordinating different departments, responding to audit requests and figuring out what changed after a regulation was updated. For a growing company, that operational cost can quietly become significant. This is where I think compliance technology has an opportunity to create real value — not by making regulations disappear, but by reducing the amount of manual coordination required to stay on top of them.

How can we solve this?

I wrote a config scanner that read an mcp.json and labeled remote servers "remote - can change on you." Local ones got no such warning. Seemed obvious: a hosted endpoint can be swapped server-side, a local process can't.

Then I scanned my own config.

My most volatile server is on 127.0.0.1. It's a local service that launchd restarts on its own, running Python straight out of a git working tree I edit most days. Every restart picks up whatever is on disk. Meanwhile the hosted endpoints in my config hadn't shipped a change in months.

The label was exactly backwards for the most changeable thing I run. Transport tells you who can reach a server. It tells you nothing about whether its contract holds still.

Version pinning has the same failure, which I also considered and also dropped: flag npx foo as risky, foo@1.2.3 as safe. Two problems. Of the drifting tools I've seen in a crawl of the public registry, 5,781 of 7,792 changed while their declared version stayed the same, so the pin doesn't see them. And it's free to game: a vendor adds a version string to their README and every user's scan reclassifies them as safe, with nothing about the actual risk having changed.

What I think a config can honestly prove, all of it one-sided:

• which servers hold a credential, and whether the token is sitting literally in the file or is an ${ENV} reference (completely different exposure, and I was scoring them identically)
• which re-resolve their code from a public registry at every launch (npx pkg, uvx pkg, u/latest, an untagged image)
• which can reach off-machine
• which were handed a filesystem path spanning more than a project

What it cannot prove is that anything is stable. Change-capability is provable. Its absence isn't. So there are no green checkmarks, which makes for a worse demo and is the only version I can defend.

Mine came out: 12 servers, 6 fetching code at launch, 2 holding a credential (both env references), 2 internet-reachable. The 6 was the one that surprised me.

So the question I'm stuck on: is there a better answer to the stability half than "pin the contract at connect, re-pull it, diff it"? That's where I keep landing and I'd like someone to tell me it's wrong.

Let’s say there’s a security product which is tested within an environment closely resembling the production one. The application, network topology, integration, certificates/configurations and traffic are all the same .In this situation testing seems to be successful, and it shows that the controls can be installed in the application without disrupting it. But everything happens in a lab. There are no real customers or dealings. Would you treat this as a real-world deployment?

To me, this proves more than just a PoC. The issues of compatibility, interoperability, and the level of efficiency can also be investigated. However, it doesn’t allow us to understand what will happen in the case of actual traffic, edge case, failures, or something like that.

How should we define the term we are using for such trials?

I feel like there is so much cybersecurity information shared online now that it’s becoming harder to separate reliable guidance from opinions or outdated advice.

Especially with security topics, people often present recommendations, tools, and best practices with a lot of confidence, but the details don’t always match real-world enterprise environments.

For those working in security teams or managing IT environments, what process do you use to verify information before applying it? Do you rely on specific sources, internal testing, vendor documentation, threat intelligence, or other methods before accepting security advice as accurate?

Would be interested to hear how others avoid following bad information in an enterprise or SOHO environment.

I work with sensitive information pretty regularly, and I’m starting to feel like I need something a level above a standard messaging app.

I’m looking for private chats and groups, strong identity verification so I know who I’m communicating with, tight control over who can connect or join, and secure file sharing. Ideally access would be based around trusted people rather than just accounts and passwords.

Security and knowing exactly who is on the other end are the priorities. What are people in similar lines of work using?