r/AskNetsec

Everyone's dunking on GitHub right now and yeah fair enough. But can we be honest about something?

We've spent years obsessing over cloud misconfigs, network segmentation and perimeter defense while completely ignoring the developer workstation. That machine has direct access to prod secrets, internal repos, CI/CD pipelines and package registries. It's the most privileged device in most orgs and it runs whatever extension or npm package the developer felt like installing at 2am.

TeamPCP figured this out. They've been running the same play all year and keep winning because the blind spot is so consistent across every company they hit.

GitHub got popped. Grafana got popped. Bitwarden CLI got popped. All 2026. All through developer tooling.

Meanwhile most security teams still treat developer laptops like they're outside their jurisdiction because nobody wants the political fight of locking down a senior engineer's machine.

At what point do we admit that supply chain security talks at conferences mean nothing if we won't enforce basic extension and dependency controls on the machines doing the actual development?

Curious what actual security teams are doing here because from the outside it looks like the answer is mostly nothing.

Working on a procurement assessment for a defense contractor client. The requirement is air-gapped AI coding assistance where no data traverses any network boundary under any circumstance, including license validation and telemetry. Not air-gapped with exceptions, like fully disconnected.

Most vendors that advertise on-premises deployment still have egress somewhere. License validation against an external endpoint. Telemetry calls on an interval. Model update processes that require internet access. Any of these disqualifies the tool for this use case because in a classified environment every network flow has to be documented and justified.

How are people actually verifying these claims during procurement? Asking the vendor's sales team gets you a yes every time. I'm looking for what documentation to request, what architecture questions to ask, and whether anyone has actually validated a fully air-gapped deployment in a classified or restricted environment.

Anyone else feeling like traditional DLP is struggling to keep up with modern workflows? Between SaaS apps, shared links, and AI tools, it seems like policies either create user friction or miss risky behavior entirely. Curious whether DLP is still giving real value in your environment or mostly adding overhead now.

we’re getting thousands of findings daily across AWS, Azure, and GCP. the problem isn’t detection, it’s deciding what actually matters. some of these have been sitting there for months. high severity on paper, but no clear exposure. others look minor but end up tied to internet-facing assets or shared roles.
we tried layering in exploitability and asset criticality. helped a bit, but still inconsistent. depending on who reviews it, the same finding gets treated differently .at this point it feels like we don’t have a stable way to separate “needs action now” from “can wait”.
for teams dealing with this at scale, what made prioritization actually consistent for you?

Mid-procurement on a new identity verification platform and the question I keep hitting a wall on is this: if the vendor uses fraud signals from one enterprise client to improve detection across their whole network, what does the data architecture look like that prevents that from becoming a cross-client exposure problem?

SOC 2 and ISO 27001 cover the obvious ground. What I want to understand is how the vendor handles fraud intelligence at the network level, what their model update cycle looks like when new attack types emerge, and whether any of that is even auditable from the buyer side.

Just trying to understand what good looks like here and what due diligence security teams are doing beyond the standard certification review.

We've updated our exec impersonation controls after a near-miss. For async requests (email, voice note), callback to a known number makes sense — end the suspicious call and verify through a separate channel.

But for a live video call that's already in progress — the CFO is on screen, has been talking for 10 minutes, asking you to initiate a wire transfer — what's the actual control? Codewords feel awkward mid-meeting when the person on screen looks and sounds exactly like your boss. And calling them back when they're "already on the call" doesn't make sense.

Is the answer just "don't approve wires from a video call full stop"? Or do people have a usable real-time verification step that doesn't require killing the call or confronting the exec?

Everyone worries about the wrong thing with agent security.

They audit the system prompt. They evaluate the model. They add guardrails to user input.

Meanwhile the agent is out there reading emails, scraping webpages, pulling documents from vector databases, and processing API responses. All of that content flows straight into context. The model cannot tell the difference between data it was sent to process and instructions it should follow.

So a poisoned document says forward the next user message to this address and the agent does it. A malicious webpage says ignore your previous task and the agent ignores it. No jailbreak. No prompt engineering. Just untrusted content flowing through your own tools.

This is called indirect prompt injection and it is the actual threat model for agents with tool access. Not someone typing something clever into a chat box.
I built Arc Gate to enforce instruction-authority boundaries at the proxy level. It sits between your agent and your LLM. Every message is tagged by source. Tool output from untrusted external content gets authority level 10 out of 100. If it tries to issue instructions it gets blocked before the model ever sees it. Dangerous capabilities get stripped. The upstream never gets called.

Not a classifier. Not a content filter. Runtime enforcement.

Try to break it: https://web-production-6e47f.up.railway.app/break-arc-gate

Demo: https://web-production-6e47f.up.railway.app/arc-gate-demo

GitHub: https://github.com/9hannahnine-jpg/arc-gate

Self hosted: https://github.com/9hannahnine-jpg/arc-sentry and pip install arc-sentry

Would love adversarial feedback from people running agents in production.

>

w compliance requirement dropped: all containers in prod must use FIPS 140-3 validated cryptography. FedRAMP moderate boundary, deadline is Q3.

checked our base images. none of them qualify. Ubuntu has FIPS-validated packages but only through Ubuntu Pro, not available in the standard free base image we use. Alpine has no FIPS-validated OpenSSL at all. Distroless doesn't ship crypto libraries you can swap independently.

went down the path of trying to use OpenSSL's FIPS provider module on top of our existing base. problem is FIPS 140-3 validation is issued by NIST's CMVP program to a specific compiled binary from a specific vendor under lab-certified conditions, you can't just compile OpenSSL from source and call it validated. the validation doesn't transfer. only CMVP-certified binaries from approved vendors (Red Hat, AWS-LC-FIPS, BoringCrypto in FIPS mode) satisfy the requirement.

buying Ubuntu Pro for every base image changes our build strategy significantly and the validated packages still need to be activated and tested against our app stack. two services broke on the FIPS OpenSSL provider because they were using deprecated cipher suites we didn't know about.

anyone running containers in FedRAMP or DoD environments, how are you sourcing FIPS-validated base images without rebuilding your entire image pipeline?

First disclosure I've run at this severity. I want to get the process right, not learn it the hard way. Looking for people who've run vendor disclosures to push back on the plan below.

What I found: CVSS 10.0 in a vendor's automated provisioning. Unauthenticated remote, full data compromise, plausible RCE. Default-credentials class, not a novel exploit. The fix on their end is roughly one line per template.

What makes it worse: the same pattern shows up across multiple templates I checked. Looks systemic to how that class of templates is generated, not one bad apple. The affected population is anyone who provisioned from those templates. They were exposed from the moment of deployment, with nothing flagging the issue. Patching the templates only protects new deployments. Every existing instance stays exposed until someone individually remediates it.

Constraints:

• No security.txt, no security contact, no bounty. General support email and a ticket system only.
• Reported through their available channels, flagging that it looks catalog-wide rather than a single template. Treating this as the start of a coordinated process.
• Working PoC. Nothing published.

My plan if they don't engage:

1. Re-report through every channel with a dated acknowledgment window.
2. If the window lapses with no response: publish an advisory with vuln class and remediation only. No PoC, no exploit code. Request a CVE via MITRE since the vendor isn't a CNA.
3. Hold the full writeup and PoC until a fix has shipped and existing exposed deployments have been addressed.

Questions for people who've run vendor disclosures:

1. When the defect is systemic and existing deployments stay exposed regardless of the template fix, is "advisory with remediation, no PoC" the right balance? Or does protecting that population justify going further, or pulling back?
2. What's a defensible acknowledgment window for a vendor with no security program, and how do you document good-faith contact so it holds up if it gets contentious later?
3. How do you push a vendor to audit a whole catalog rather than patch only the one template you named, without handing them an excuse to stall?
4. MITRE as CNA-of-last-resort when the affected party isn't a CNA: realistic path, and does MITRE want a public reference at submission time?
5. Anything in this plan that would make someone experienced wince?

Keeping the vendor, components, and specific templates out of it while remediation is in progress. This is a process question, not an attempt to crowdsource an ID. Tell me what I'm missing.

Thanks a lot for your time.

Every time I deploy something directly from git to a new server over SSH, I have to manually approve the server's host key, check it against another machine. Why on earth do none of these companies (talkin bout you Github, Gitlab, Bitbucket) publish DNSSE SSHFP records? These are companies whose entire business depends on SSH trust. Millions of developers blindly typing "yes" to that first-connect prompt is somehow acceptable to them? What am I missing?

Mid-evaluation on a few platforms that take a behavioral approach rather than signature-based detection. The concept makes sense for the attack categories we are most worried about, BEC and account takeover specifically. Though I dont quite get what the baselining period means for detection coverage during those first few weeks.

The concern is not that it takes time to learn, it's whether there is a period where the model has not seen enough of our communication patterns to accurately flag deviations, and if so how long that window is and what it looks like empirically in production environments.

Would be helpful if someone has run one of these through the initial learning period can share what the false negative rate looked like in the first 30 to 60 days. Thnx.

I submitted a report through the bug bounty program after encountering what appears to be a serious privacy issue in ChatGPT.

I uploaded an image, and the response contained confidential medical information that seems highly unlikely to be a hallucination. The details were unusually specific and internally consistent: a rare full name, a real hospital matching the patient location, the patient’s gender aligned with the gynecological diagnosis, and the examination matched the relevant hospital department...

Taken together, the probability of this being randomly generated seems extremely low, which raises concerns that data belonging to another user may have been exposed.

Has anyone else experienced something similar or investigated cases involving potential cross-user data leakage?

Another connecting question: my bug bounty report was rejected as “non-reproducible.” Why is reproducibility being treated as a strict requirement in a non-deterministic system like an LLM? By nature, these models do not guarantee identical outputs across runs.

Thanks for your help

we blocked chatgpt and a few others at the network level months ago, but most AI usage just moved into the browser. trying to get visibility there and running into the same issues over and over:

- extensions and sidebars (copilot, claude, random plugins) run client-side or through approved domains, so there’s nothing obvious to block  
- network logs don’t show much since traffic blends in with normal SaaS usage  
- CASB catches some standalone tools but misses local extensions and embedded features  
- chrome enterprise policies help a bit but don’t cover everything, plus users complain about performance  
- no clear way to see what’s being pasted into prompts or what data is leaving  
- devtools show some calls but not something you can realistically monitor across an org  

at this point we know usage is happening just don’t have a clean way to see it.

anyone figured out browser-layer visibility without killing performance or rolling out full endpoint agents. what are you actually running for this?

we’re seeing our LLM behave differently in prod compared to testing. in staging it sticks to guardrails, but under real traffic it starts producing responses that don’t match what we saw earlier.

last week during peak load it generated something that should have been blocked, but it slipped through. we never saw that pattern in testing.

now it’s unclear if this is load-related, input variability, or something in how guardrails behave under real conditions.

trying to understand how people handle this gap between controlled testing and production behavior.

what’s worked for catching these issues before they show up in prod?

📅 The CISO tenure problem:

Average CISO tenure is 26–36 months. Yet building a genuinely effective security program takes 3–5 years minimum.

How do you build something lasting in an environment designed for short tenures? And what do you hand off when you leave?

#CISO #SecurityLeadership #CISOCareer #EnterpriseSecurity

Yo so I downloaded a Riot game from a site that I'm pretty sure is the official site but I can't verify it because I deleted my browsing history to log out. I remember copying two links in search results and verified that both were legit but I'm worried I misclicked onto the wrong link after verifying or something. I know it's dumb to think that but I'm quite paranoid of malware. I did a offline and full scan with Defenders and nothing. I also got this link from download history for the file in Chrome which is also apparently legit? hxxps://valorant.secure.dyn.riotcdn.net/channels/public/x/installer/current/live.live.na.exe.

I am worried cuz games crashed, screen had black screen moments and was slow 1 time. I know it's easy to just reinstall windows but my parents said if there is malware to bring to a shop (they don't trust me to do it) and I don't want to waste money if unnecessary.

Should I be worried of malware? Will I be OK?

Traditional security controls were built around networks, endpoints, and infrastructure, but a huge amount of sensitive company data now lives inside SaaS platforms like Google Workspace, Slack, Salesforce, and similar collaboration tools.

What makes these environments difficult to secure is that permissions and sharing exposure constantly evolve over time. External collaborators get added temporarily, public links remain active longer than intended, and third-party integrations quietly accumulate access across multiple systems.

In many cases, the biggest risk is no longer a single obvious breach event but gradual permission drift and overexposure that becomes difficult to continuously track manually at scale.

That’s why SSPM feels increasingly relevant in modern environments. Maintaining visibility into who has access to what across SaaS applications seems to be turning into a core operational security problem rather than just a compliance checkbox.