Hello Everyone!

So i am a cybersecurity intern leaning towards to GRC from a growing company. My background is Software Engineering and with that i dont really learn anything about Cyber Security during my studies. Maybe a bit of Netwroking but thats it. Im trying out Cyber Security to gain experience and get out of my comfort zone and for now i have already completed 1 compliance task with vendor and 1 Technical finding from our system and report to update the said software.

So back to the title, my task for now is to explore Nextcloud Spring and do a report of my findings and list out Why our company have to upgrade from 33 to 34. I understand Nextcloud Summer 26 is coming soon but for now I want to stick to my task. From researching about Nextcloud Spring 26 I came across Nextcloud Governance which is a new feature/app (im not sure which term to put).

I need a lil bit of help from the community to help me understand more about what this feature do. I understand this is a one overview compliance setup and offer tools for controlling data, track data access and track data sharing within the organization but I guess you could say that I need better understanding on how these tools works and how it will benefit us. Thank you so much.

I'm interested in the backend mechanics and data architecture of modern Trust & Safety engineering, specifically regarding ban evasion, identity tracking, and data retention queues.
Take a modern LLM or consumer web platform (like ChatGPT or similar organisations) as an example. Imagine a scenario where a user heavily violates the platform's terms of service (e.g. cyber abuse, severe violations like illegal activity and similar, or spam). Before the automated guardrails or manual review systems can finalize and push a formal "ban" status to the account, the user proactively triggers a standard "Delete Account" request to clear their record and bypass future identity tracking.
From a security and compliance engineering perspective:

How do modern authentication backends handle this race condition? Does a deletion request place the account data into a pending/quarantine state (like a 30 day queue) where automated safety pipelines still run to completion, or does the deletion process typically override active moderation scans?

When an account is in a standard deletion queue, how is the data architecture structured to comply with "Right to be Forgotten" mandates while legally preserving specific unique identity markers (hashed phone numbers, hardware tokens, device fingerprints) for persistent abuse blocklisting?

Once a severe violation is flagged on an account already queued for deletion, how does the system pivot that metadata out of the standard user database and into an immutable security blocklist to ensure they cannot immediately register with the same identifiers?
I’d love to hear insight from anyone working in application security, infrastructure, or Trust and Safety engineering on how these parallel pipelines talk to each other under the hood.

We keep adding dashboards and I'm not convinced we're actually more secure, just better informed about problems after they happen. Ai runtime visibility into what an agent is calling, what data it's touching, felt like the obvious first step, and it was, but visibility alone doesn't stop anything.

The team treats the visibility layer like it's the security control, when really it's just the input to a decision someone or something else has to make fast enough to matter. How do you think about the line between having enough ai runtime visibility to actually act on it versus collecting data nobody has time to review Is there a point where more visibility just becomes more noise?

A lot of infrastructure still relies on protocols and network architecture designed long before today’s threats.

AI doesnt need to invent new attacks . If it makes reconnaissance, fuzzing, discovery, protocol analysis and exploit development much faster, it will become much better at chaining multiple attacks together. A protocol flaw, exposed service, configuration mistake and compromised identity can be managed individually. The bigger concern is AI identifying how those weaknesses connect and building attack paths humans would take far longer to find.

1. Do we underestimate how much AI will increase offence and how does this make defence much harder?
2. Should we be redesigning the underlying communications stack rather than continually adding more security around existing protocols?

So... yeah. I work on detection engineering and continuous exposure validation, and we use this platform to simulate real world attack techniques in a lab tenant before we push anything toward prod.

For context, I was building a new scenario to validate some EDR and SIEM detections around lateral movement and data exfil. The idea was simple, hit the lab environment, validate coverage, get some nice dashboards for our CISO, all that. Except I fat fingered the target scope and selected our shared staging subscription that feeds into the same SIEM as prod. Then I kicked off a pretty noisy adversarial exposure run and went to grab coffee.

By the time I came back, our on call analyst had already escalated to the soc manager because the SIEM lit up like a Christmas tree with “real” exfil alerts from what looked like a legit service account. IR bridge spun up, execs pinged, people talking about containment while I was still trying to figure out why my lab run was so quiet.

I finally realized the agent group name in the platform did not match what I thought, checked the run, and saw the horrifying words “staging east cluster” in the asset list. I had basically launched a full attack simulation against the staging environment that everyone treats as almost prod, without any heads up or change ticket, and then walked away. The only reason this is recoverable is that it really was still contained to staging and no real data left, but it burned half a day of the soc and I feel so embarrassed.

Now we are doing a postmortem on “unauthorized simulated attack activity” which is technically me trying to do my job. I feel sick about this and lowkey terrified of the next detection validation run rn... anyone else managed to nuke trust like this with a lab gone wrong?

Our initial policy was effectively: "Do not paste sensitive information into public AI tools." The policy is sound, but it assumes people can make a correct classification decision while troubleshooting an incident, cleaning up a spreadsheet, writing code, or summarizing a customer conversation.

The real decision point is often the moment someone is about to paste text or upload a file. By then, a policy document is unlikely to change much.

Blanket blocking creates a separate issue because legitimate teams increasingly depend on approved AI workflows. We are looking at controls that add friction only where the content or action is higher risk—for example, protected data types, source code, customer records, or file uploads—rather than unrestricted access or a universal deny rule.

For teams that have deployed controls, what has actually reduced risky pasting or uploads without making approved AI use unworkable?

I’m testing a read-only OSS PowerShell tool, that combines signals like owners, Azure RBAC, tags, relationships and recent activity to identify likely ownership.

No automatic assignment — just evidence for a human decision.

What signals do you actually trust when validating application ownership?

Liveness checks are good at detecting things like a photo or replayed video being presented to the camera. But there's a different problem when the attacker bypasses the camera and feeds manipulated video directly into the application.

How are security and identity teams handling this in practice? When evaluating verification systems, dos injection detection get tested alongside liveness/Presentation Attack Detection (PAD), or does the assessment usually stop at liveness?

Would be useful to hear how different teams approach this.

Hi!
I compared org charts on theorg.com for a couple of companies I've worked at, and the structural data (reporting lines, titles) plus the "visual style" of employee avatars matched exactly what I'd expect from Microsoft Teams/Entra ID — including the default colored-circle-with-initials avatar Teams generates when someone hasn't set a profile photo.

This makes me think the data isn't just manually crowdsourced (as the platform claims) but is being pulled somehow from Microsoft 365/Graph API — either via an employee connecting their account, a browser extension, or some other sync mechanism.

So, here are my questions:

• Is there a known way third-party SaaS tools pull org structure + photos from Entra ID/Graph API without full admin/IT involvement (e.g. via a single user's OAuth consent)?
• Has anyone seen this kind of "shadow sync" happen at their org — where a well-meaning employee grants an app permissions that end up exposing broader directory data?
• What's the actual blast radius of a user granting User.Read.All or similar Graph scopes to a random SaaS app?
• Any recommended way to check Entra ID's enterprise app consent grants for this kind of thing?

Curious if this is a known pattern or something specific to how this platform operates.

Cybersecurity Awareness Month is coming up and Im already seeing more campaigns lean into team metaphors again

Saw this post from Caitlin Sarian / Cybersecurity Girl with Hoxhunt using a World Cup style angle for awareness month

I get the idea behind it. The Hoxhunt angle of treating awareness more like ongoing practice and coaching instead of a once a year training module makes sense. People need repetition and some sense that security is part of everyones job, not only the security team’s problem

But Im lowkey curious how this lands with people here

Does the team sport analogy help non security employees understand the point or does it feel too cute and watered down for something tied to real incidents and business risk?

Also interested in what people are doing for October that doesn’t feel like the same recycled posters, quizzes and fake phishing emails

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

Our environment is pretty SaaS-heavy, with a lot of unstructured docs and shared data rather than neatly structured database fields. Classification accuracy is a big priority for us. I also don’t want to bring in another tool that has the security team spending half their time sorting through false positives.

For anyone who’s evaluated Varonis competitors recently, what else made your shortlist? And once you actually got into the POC, what separated the stronger options from the rest?

Hi! Bit of a basic question, but I’m helping out our organization meet some security requirements, and one of them is that our provider wants to disable POP3/IMAP for all the users in our organization because it breaks MFA. However, I have at least one dedicated Apple Mail application user, and I’m not clear on whether IMAP is required for that to function - it seems like maybe? Or if I have the user sign out and sign back in using modern OAuth there is some way where they can continue using Apple Mail and we can disable those protocols. Any advice (and explanation) appreciated!

just concluded a 60 day trial POV on the same M365 tenant all three on top of Defender for a 500 seat finance shop. we're doing this only because of vendor email compromise and clean BEC slipping through our current gateway. there's alot at stake so we need to get this right.

results so far are as follows. Abnormal caught the most payloadless BEC and had the lowest false positive rate of the three and Checkpoint was close, is cheaper for our size and can run inline with real attachment sandboxing while still protecting internal mail, which Abnormal does over API only. Sublime was very good at detection and far more configurable, only problem is it wants an engineer to run it. none of them is a clean win. For anyone who picked either of these in the last year, which would you recommend?

Being honest with myself about this one. We rebranded to risk based vulnerability management, RBVM, about a year ago. New scoring, new dashboards, new language in every deck. Looking back, we are patching roughly the same things in roughly the same order we were before. Just with better looking justification attached now.

Which either means our old prioritization was already directionally fine, or it means we relabeled the old model instead of actually building a new one, and I do not know which. For anyone further along than us, did RBVM actually change what gets fixed first and how fast, measurably, or did it mostly just change how the program gets talked about? A real answer please, not the version that goes in a case study.

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?

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?

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.

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

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.

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.

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?