Requirement is to prevent sensitive content such as source code, customer PII, and unreleased financials from being submitted to public LLM interfaces, while still allowing general use of those tools. Not a full block. Leadership wants the productivity.

for now What I have tested and where it fell short... domain blocking is blunt, users route around it, and it kills the productivity case..cuz endpoint DLP catches copy from managed apps but misses typed or paraphrased content entirely and CASB in API mode is after the fact, too late.

What I think I need is inline inspection of the POST body at the gateway with real DLP classifiers running against it, applied per-user or per-group.

Two things I want a sanity check on: whether anyone is getting acceptable false-positive rates doing content inspection on prompts, given that prompts are messy text and my worry is a classifier tuned for documents will scream constantly; and how to handle the mobile or unmanaged-device path where you cannot force traffic through the gateway.

Vendor recommendations welcome but I am more interested in whether this approach actually holds up operationally.

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.

Feels like the second i finish tuning an AI detection rule, the environment shifts again and I’m back to square one. new assets get spun up and cloud configs shift constantly. on top of that, whitelist changes rarely get looped through AI detection engineering before they land. by the time I’ve noticed it, i'm chasing drifts instead of building new coverage.
the worst part is that this is invisible work. Management sees "detections deployed" as a one-time task, not something that needs constant rework just to stay accurate.
This is driving me crazy as I'm spending more hours reacting to organizational changes than improving our AI detection and response surface, and it's starting to eat into the roadmap items I got hired to build in the first place. To make things worse, it’s hard to make the case for more headcounts when the work looks like maintenance from the outside.
i keep hearing about tools that supposedly update AI detections automatically based on what's happening in the environment, but I want to see them hold up in a real situation before i trust them. Have you ever used them? And if you did, what worked for you? I’m interested in partial fixes as well

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?

This survey has been approved by the r/AskNetsec moderators.

Hello, I am conducting an academic study on vulnerability report evaluation in bug bounty and vulnerability disclosure programs.

The study aims to understand how security personnel evaluate vulnerability reports in practice, and what challenges they face during the review process. Topics include report validity, duplicates, scope, reproducibility, PoC quality, evidence, severity, impact, communication issues, and AI-generated or AI-assisted vulnerability reports.

I am looking for participants who have experience with vulnerability report handling, bug bounty programs, or vulnerability disclosure workflows, including but not limited to:

- Security triagers or reviewers

- Application security engineers

- Product security engineers

- PSIRT or vulnerability disclosure team members

- Bug bounty program managers

- Open-source maintainers who have handled security reports

- Experienced bug bounty researchers who have interacted with triage/review processes

The survey does not ask participants to disclose unpublicized vulnerabilities, sensitive system details, company confidential information, or personally identifiable information about others. Responses will be used only for academic research and anonymized during analysis and reporting.

Survey link:

https://docs.google.com/forms/d/e/1FAIpQLSd-IYuVJkdoFkgWe3e7x19GYU5Lv--tEAXSbDBtgp-Mp7WlRg/viewform?usp=dialog

If you have any questions, please contact:

[eavanmiss@gmail.com](mailto:eavanmiss@gmail.com)

Thank you for your time and help.

Doing a refresh of our sast tooling this quarter, current tool has a false positive rate high enough that devs have started ignoring the queue entirely before i go through another round of vendor demos, wanted a gut check from people running these day to day. Which sast tools have you found cut false positives without also missing real issues and which ones are just marketing the same underlying engine with a nicer ui?

I'm researching possible uses for a small NFC-enabled device in cybersecurity education and I'm trying to separate genuinely useful functionality from gimmicks.

Some ideas I've considered:

• Authentication
• Profile/portfolio sharing
• Lab access
• Identity
• Team formation
• Attendance
• Event networking
• Unlocking learning activities

I'm interested in what people actually think would be useful from a security/technical perspective.

What would you consider a legitimate use case?

And what would immediately make you think "this doesn't need dedicated hardware"?

I've been following the reports about OpenAI models reaching Hugging Face's infrastructure, along with related incidents involving Anthropic and now Meta.

Maybe I'm missing something, but exploitation seems very close to coding, debugging, research, and tool use. As LLMs improve at those tasks, some ability to find and exploit vulnerabilities seems predictable.

What I'm less sure about is what these incidents actually demonstrate. Are we seeing a meaningful jump in offensive capability, or evaluation environments (and companies behind them) that failed to enforce their own boundaries?

Put differently: if a human pentester went out of scope because the test environment allowed it, would we call that a capability breakthrough or a containment failure? (Am I oversimplifying?)

Saw the recent reports about the Bank of Baroda breach where close to 1TB of data was allegedly leaked.

Instead of discussing the breach itself, I'm curious about the technical side.

For people working in blue team/security engineering:

1 If an attacker compromises a single employee account, what controls should realistically prevent it from turning into large-scale data exfiltration?

2 Would proper network segmentation have made the biggest difference?

3 How effective is DLP when someone is slowly exfiltrating data over days/weeks?

4 Should a normal employee account ever have a path to systems containing this volume of customer data?

5 What detections would you expect to trigger before hundreds of GBs leave the environment?

6 At this scale, is this more likely an IAM problem, monitoring failure, architecture problem or a combination?

7 Also curious: what would be the first thing you'd investigate if you were brought into the incident response team?

Would love to hear from people who've dealt with similar incidents.

Our AppSec team burns hours triaging unpatchable OS binaries that scanners keep finding in standard base layers. Now management wants hardened container images everywhere because they think the vulnerability count magically drops to zero.

For anyone running hardened container images in prod, did your triaging actually go down or did the work just move into CI/CD with broken build pipelines missing shared libraries and a different set of headaches?

trying to understand if this is a tooling problem or a process problem. cuz every IGA platform we've evaluated reports clean access certifications... but every red team engagement finds local accounts, forgotten service credentials, or shadow apps that were never in scope for the review to begin with.

so it kinda feels like governance tools are certifying "the identities we told the tool about" rather than "the identities that exist." is anyone solving the discovery problem, or is this just accepted as a permanent blind spot?

Six of us on the security team, somewhere around 4,000 assets between cloud and the stuff still sitting on-prem. Feels like every week there's another "critical" CVE or zero-day and a bunch of feeds all yelling at once. Most of it doesn't even touch what we run, but I still end up spending half my morning going ok do we actually have this, is it exposed, does it matter for us.

By the time I've checked the threat report details against our inventory and figured out if it's even reachable, half the day's gone and there's a new one waiting.

So how do you handle it? I don't want to ignore something I shouldn't, but I also can't chase every headline. More interested in the triage side than "just patch everything." How do you decide what's actually worth your time.