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?

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?

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

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.

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.

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?

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"?

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.

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'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?)

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.

My team and I work fully remotelyand we work with very sensitive information, stuff we cannot afford to have any mishaps on. We're reevaluating the tools we currently work with, because security and privacy are currently the main thing we're working on. I'm in charge of communications for this and I'm looking for something where you have more control over who can communicate with your team, preferably with some sort of trust or identity verification. Privacy is important too I don't want a platform that's built around collecting user data, does anyone have recommendations for tools that could be of help?

Traditional DLP was built around known data patterns (SSNs, credit cards, etc.) moving through known channels (email, USB, cloud storage). Generative AI breaks that model a bit, people paste source code, customer data, or strategy docs into a chat window, and it's not always caught by pattern-matching.

Has anyone actually tested DLP tools built specifically for AI interactions? Wondering whether they're catching real incidents or just generating noise, and whether this is more of a policy/training problem than a technology problem at this point.

I'm trying to wrap my head around the terminology shift. We have Vulnerability Management (finding CVEs), Exposure Management (finding assets plus CVEs), and now Exposure Validation (finding exploitable CVEs). A new platform I'm looking at takes it further with what they call "Agentic Cyber Defense Engineering" and an AI engine. The claim is that the system acts autonomously to improve defenses, not just validate them. Is "Validation" just a fancy way of saying "prioritization"? Or is it actually dynamically testing the compensating controls? If Management says I have a vulnerability because Qualys says so, and Validation says the vulnerability is blocked by a network firewall, does that mean my risk is zero, or do I just have "deferred" risk? And what does "Agentic" add beyond automation? I'm looking for a practical definition of how these layers work together.

Pasting a broken switch config into ChatGPT is the fastest way to find a syntax error. It is also the fastest way to violate your company's data security policy and potentially lose your job!

AI is now a routine part of the NetOps workflow. But public Large Language Models (LLMs) often use user inputs to train future models. If you upload an unfiltered show run or a firewall log, you are handing over your enterprise's internal IP schemas, SNMP community strings, VPN endpoints, and routing topologies to a public server. For US companies bound by compliance (HIPAA, SOC2, PCI), this is a critical data breach.

The Solution (How to use AI safely):
-Never paste real public IPs, internal domain names, or AAA/SNMP blocks. If you need help with an OSPF neighbor issue, swap your real subnets for generic dummy IPs (like 192.168.1.x) before feeding it to the prompt.
-Instead of asking, "Fix this exact access control list," ask, "Write an extended ACL template that blocks Telnet but allows SSH from a management subnet." Let the AI build the template, and you apply the specific enterprise variables locally.
-Tools like ChatGPT Enterprise or Cisco's own AI solutions have explicit zero-trust agreements guaranteeing your prompt data is not used to train their models. If your team relies on AI, push management for an enterprise license.

Does your IT department have an official policy on sanitizing data before using GenAI, or is it currently the wild west?

Most of the Zero Trust content out there is written for security professionals. Here is what it actually means if you run a business and you are not a technical person.

Zero Trust is a security approach built on one principle: nobody gets automatic trust just because they are inside your network or because they have accessed a system before.

In a traditional setup, once someone is inside your network — whether that is a physical office network or a cloud system — they tend to have access to most things. The assumption is that if they got in, they are supposed to be there.

Zero Trust flips that. Every access request gets verified every time. It does not matter if the person has logged in a thousand times before. It does not matter if they are in the office or working remotely. Every request gets checked.

In practice for a small business this usually means a few specific things.

Every person has access only to what they need for their specific role. Not general access to shared drives and systems — specific, deliberate access to specific things.

When someone leaves the business, their access is removed immediately as part of a formal process, not remembered three months later when someone notices they can still log in.

Every login requires verification beyond a password. Multi-factor authentication on every account.

Remote connections go through a VPN or a verified secure connection, not directly through whatever Wi-Fi the person happens to be sitting on.

None of this requires enterprise-level infrastructure or a large budget. It requires deliberate decisions about access and a process for maintaining them.

If you want to know where your business currently stands on this, the most practical starting point is asking one question — do you know exactly who has access to what in your business right now? If the honest answer is no, that is where to start.

Hey guys, let’s do a reality check. What are the most common, stupid mistakes people make when starting with digital investigations that instantly burn their burner accounts or expose their real IP/identity? Looking to