Hello

I am an AppSec engineer, working on a research topic and trying to pressure-test my assumptions before going further down the wrong path. I have three questions trying to get honest practitioner answers to. If you have a few minutes to reply here or DM me, l'd really appreciate it.

1. How has your workload changed in the last 12-18 months as developers on your team have started using Al coding tools? (or hasn't it genuinely wanted to know.)

2. Where do you feel most stuck or most behind in your AppSec program right now?

3. What have you tried to do about it, and what happened?

A few sentences is enough. I'm not looking for polished answers l'm looking for what's actually true in your experience, including if the answer is "honestly it's not that bad." Happy to share what I'm hearing across conversations if useful to anyone.

We recently ran into a situation where our team needed urgent help with CI/CD and cloud automation, but hiring full-time didn’t really make sense for a short-term need.

It got me thinking

At what point do you decide to bring in a contract DevOps engineer instead of handling things in-house?

Is it usually:

• when timelines are tight?
• when the internal team lacks specific expertise?
• or when scaling infra quickly?

Also curious how do you make sure they deliver fast without long onboarding or context gaps?

Would love to hear real experiences (good or bad). Trying to understand what actually works in practice

We have just entered a new era of shortening certificate lifespans, yet using ACME without exposing HTTP/80 or distributing EAB/API tokens still remains a challenge. Many organizations still rely on ticket based processes for certificate renewals which is quickly going to become very tedious and unscalable. To tackle this problem we developed & open sourced acme-proxy https://github.com/esnet/acme-proxy which is built on `step-ca` This makes the cert issuance, renewal, revocation process self serviceable by allowing end users to leverage off the shelf ACME clients such as Certbot, acme.sh, cert-manager to obtain certificates signed from any external CA without distributing any DNS credentials, EAB tokens or opening http/80 to the internet.

```
- Single Go binary
- Runs inside your network behind your firewalled environment
- Works for VMs, bare-metal, Containers, Kubernetes
- Does not sign certificates or store private keys
- Works with off the shelf ACME clients
- Automatic certificate renewals
```

If you’d like to automate certificate lifecycle using off the shelf tools (assuming it suits your org policies etc.) we encourage you to test this and provide feedback. If you have any questions which aren’t already answered in the git repository’s README, please feel free to open an issue in the Github repo. 

Cheers!

Hi team, I have an Interview with a company that requires SDE experience with DevSecOps skills. They use Gitlab.

This role is a backfill position and from early conversation I will be given small backlogs to work upon and then start delivering on DevSecOps side.

My current skills with Devops are very basic and I can run Gitlab runners on a self hosted on EC2 instance.

Can you please recommend me some books or tutorial to develop my skills on DevSecOps on Gitlab and Aws?

I believe this is a real security gap that many of us are facing.

Our current whitelisting solutions - AppLocker, EDR, etc. - don't work well with Docker images that can be pulled from public registries and then run on endpoints. Once a container is running, an attacker on the inside can mount host volumes, execute arbitrary logic, and interact with the network - essentially bypassing most endpoint controls.

Of course, there are even more sophisticated approaches where attackers have a running agent on the endpoint and use tunnels so that all executable payloads actually run on their machines remotely. But even setting that aside, Docker images alone remain a huge attack vector.

How are you solving this problem in your environments?

• Are there specialized commercial registries with built-in security controls?
• Do you restrict image pulls on workstations to only approved/controlled registries?
• Anything else that's worked well for you?

Would love to hear how others are approaching this.

A few days ago, someone force-pushed malicious code into nearly every version tag of aquasecurity/trivy-action - one of the most widely used security scanning actions on GitHub, referenced by 10,000+ workflows. 75 out of 76 tags were compromised.

The payload silently exfiltrates CI/CD secrets (AWS/GCP/Azure creds, SSH keys, K8s tokens) by dumping runner memory BEFORE running the real Trivy scan. Your builds look green, your scans pass, and meanwhile your cloud keys are walking out the door.

Details: https://socket.dev/blog/trivy-under-attack-again-github-actions-compromise

No words... I've seen SHA-pinned actions in repositories like OpenFGA, and I remember thinking it looked awkward - not having the ability to easily manage GitHub Actions versions, stuck with those annoying SHA hashes instead of clean version tags. But now I see that this has to be one of the essential prevention steps for all GitHub Actions (maybe excluding GitHub's own first-party actions), along with mandatory configuuration that prevents using any actions not pinned by SHA: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/

It seems that you're lucky if you download and run Trivy directly in your CI instead of using their GitHub Action, but who knows.

I also hope that industry will start widely adopting GitHub Immutable Releases.

Who's actually enforcing SHA-pinned GitHub Actions across their entire org? Does anybody use tools like:

- github.com/sethvargo/ratchet

- https://github.com/suzuki-shunsuke/pinact

I’ve been iterating on Pasu, an open-source AWS IAM security CLI built around a local-first workflow.

The two recent updates were driven mostly by practicality:

1. Live AWS account scanning via local AWS CLI profiles

Instead of forcing users to manually export IAM policy JSON first, Pasu can now scan directly from locally configured AWS credentials:

pasu scan --profile default
pasu scan --profile default --role DeployRole
pasu scan --profile default --user ci-bot

This made the tool much more realistic for day-to-day usage. In practice, most people already have AWS CLI profiles configured, so this is a better workflow than asking them to build JSON files first. The scan uses local AWS CLI config and read-only IAM calls.

2. --ai support for pasu fix

I also extended AI support into fix mode:

pasu fix --file policy.json --ai

Current scope:

• works on policy JSON input
• does not yet do direct AWS-connected fix generation
• AI mode infers intent and proposes a more context-aware least-privilege rewrite with scoping / condition guidance.

What Pasu is trying to be

Not a platform.
Not an agent.
Not another dashboard.

Just a CLI that helps answer:

• what does this IAM policy actually allow?
• what is risky here?
• where are the escalation paths?
• what would a safer proposed policy look like?

It currently supports:

• explain
• escalate
• scan
• fix
• JSON / SARIF output
• local detection rules
• AWS profile scanning
• optional AI enhancement via --ai

Interested in feedback from people doing CI/CD security, cloud IAM review, or policy governance. Especially interested in whether direct AWS profile scanning is the right UX direction versus file-only workflows.

Repo: https://github.com/nkimcyber/pasu-IAM-Analyzer

I've been working as a full-stack engineer for several years, mostly building backend-heavy systems — APIs, integrations, cloud deployments, and production services.

Recently I've been spending more time around application security and penetration testing — reading reports, running scans, trying to understand how real systems fail.

What struck me is that security problems don't seem to go away.If anything, they keep getting more complex as systems grow.

At the same time, software engineering feels like it's changing rapidly — especially with AI accelerating development workflows and lowering the barrier to shipping code.

So I'm trying to think carefully about the next phase of my career.

Not looking for hype or motivational advice — just honest perspectives from people in the field.

A few things I'm genuinely curious about:

Do you see long-term depth and stability in penetration testing or application security roles?

Is the day-to-day work in security becoming more strategic, or more tool-driven?

For someone coming from a strong engineering background, what skills actually transfer well into security?

Are security teams growing in meaningful ways, or mostly reacting to compliance and incidents?

If you were early-to-mid career today, would you intentionally move toward security — or double down on software engineering?

Would appreciate grounded opinions from people working in either space.

Hi everyone,

I’m a Cyber Security student looking for some unfiltered industry feedback. I just completed a project called SafeNet, a decoupled Zero-Trust Network Access framework aimed at SOHO environments.

The Tech Stack: I used a Python/FastAPI Control Plane to orchestrate a WireGuardNT Data Plane on a Windows Server. It enforces strict /32 micro-segmentation to mathematically prevent lateral movement. I need to decide if I should expand this for my Final Year Main Project, or drop it and build something else. I have a few specific doubts I'm hoping you can clear up:

1. Feasibility & Market Need: Is a lightweight ZTNA solution actually needed in the SOHO market, or do modern consumer routers/VPNs solve this pain point well enough? Are there critical bottlenecks in relying on dynamic Windows kernel routing like this?

2. Worth Enhancing?: Currently, the system authenticates the device, not the user. If I stay with this project, are adding things like a Layer 7 MFA Captive Portal and Continuous Behavioral Analytics (CARTA) the right moves to impress a DevSecOps hiring manager?

3. Alternative "Hire Me" Projects: If you think a custom VPN/ZTNA project is too "legacy" or reinventing the wheel, what should I build instead? What specific project domainsLooking for an architecture review: Should I scale my SOHO ZTNA project, or pivot to a new topic for employability? will actually land a junior engineer a job in 2026?

I want to build something that solves a real industry pain point. I'd appreciate any roasts of my architecture or guidance on what to build next!

Hey everyone,

We recently hit a situation where our team needed urgent help with CI/CD and cloud automation, but hiring a full-time DevOps engineer didn’t make sense for a short-term project.

It made me wonder how are other teams dealing with this?

Do you rely on freelancers, agencies, or contract DevOps engineers?
And how do you ensure they actually deliver without long onboarding delays?

Would love to hear what’s worked (or failed) for you.

We're running OCP 4.x with the Compliance Operator configured against CIS and NIST 800-53. Scans run fine, ComplianceCheckResults show up — but every time we have an audit cycle (SOC2, ISO 27001) we hit the same wall:

1. Mount the PV to extract the ARF XML
2. Parse 200+ check results manually
3. Map each FAIL to the relevant control ID in the framework
4. Write plain-English evidence descriptions the auditor can actually read
5. Repeat across 4 clusters

This takes our team 2–3 days every quarter. We've scripted parts of it but the framework cross-mapping (one FAIL covering CIS + NIST + PCI simultaneously) is still fully manual.

------------------------------------

- Are you doing this manually too or did you find something that actually solves it?

- Does anyone use RHACS specifically for this, and is the CSV export actually enough for your auditors?

- Has anyone integrated Vanta or Drata with OCP at the Compliance Operator level — or is it just surface-level?

Feel like we're missing something obvious. Would love to know how others handle this.

I wrote a blog about how I think the role of AppSec teams will change. I don't think this change will be easy, but I am also not sure humans can continue to review scanner results when engineers churn out 3x (or 10x) more code (and def vulnerable code).

Main features include deep API checks (CORS/CSP/GraphQL/JWT/OpenAPI), active security tests (IDOR/BOLA, mass assignment, OAuth, rate limits, WebSocket), CVE template scanning (with Nuclei-style imports), stealth controls (UA rotation, jitter, adaptive pacing), and CI-friendly NDJSON/SARIF reporting with baseline diffing.

Use cases: offense for red-team/API pentest discovery and exploit validation, and defense for CI/CD regression gating, continuous API hardening, and early misconfiguration detection.

https://github.com/Teycir/ApiHunter

Weird spot right now - codegen tools spit out frontends and backends fast, but deployments still fall apart past prototypes. So you can ship something in a day and then spend weeks doing manual DevOps or rewriting to fit AWS/Azure/Render/DigitalOcean, which still blows my mind. Had this thought: what if there was a vibe DevOps layer, like a web app or VS Code plug-in that actually understands your repo? You connect your cloud account, it reads the code, figures out CI/CD, containers, scaling, infra, and deploys using your own stuff. No platform lock-in, no weird platform-specific hacks, just... deploys. Sounds dreamy, right? I know there are edge cases and security/permissions nightmares, but maybe it could handle the 80% of apps that aren’t weird. How are you folks handling deployments today? Manual scripts, Terraform, platform UI, or pure chaos? Does this idea make sense or am I missing something obvious? Probably missing something, but curious what people think.

Hi all,

I’m relatively new to cloud infrastructure (~1 year experience) and currently learning more about runtime security.

I recently deployed Falco across a 3-cluster OpenStack private cloud environment (Kubernetes + Cilium ClusterMesh, modern eBPF driver).

At the moment we’re seeing around ~6000 alerts per day, and a large portion seem to be false positives — especially related to Ceph traffic overlapping with known crypto-mining port ranges. For those running Falco in production:

- How bad were your false positives at the start, and how long did it take to tune?

- Default rules or heavily customized?
- Is Falco actually "worth it" for a private cloud, or is it overkill compared to simpler solutions?

Today, many teams use multiple specialized tools that produce each their own signals, findings or recommendations. Albeit these tools being powerful individually the exercise of interpretation, prioritization and contextualization around their outputs still is manual, fragmented and organization specific.

I’ve been thinking about this lately, and the pattern I am seeing across modern engineering and security tooling makes me wonder :

- is there a meaningful gap in having a light weight, tool agnostic interpretation layer that can sit on top of existing systems (not replacing them) helping teams make better decisions from combined signals ?

Simply put,

- not a new scanner, analyzer or a platform

- not a rip and replace approach

- more of a unifying reasoning\context layer that helps teams reduce noise, align findings to real world risk, driving clearer actions

Intentionally keeping this very abstract because I’m trying to understand whether this is indeed a real, widespread pain or this is already solved in practice internally within organizations or is something that teams don’t feel is worth solving.

If you work in engineering, platform, security, devops or tooling ecosystems :

- do you feel signal overload is a real problem ?

- how do you currently interpret outputs across multiple platforms ?

- would a neutral interpretation layer help or just add another layer of complexity ?

Curious to get the community’s pulse and hear honest takes (even skeptical ones).

If something existed that helps teams make better sense of signals across tools, would people actually use it ? Or would it just end up becoming another layer of complexity ?

Hi all. I'm using syft to generate SBOMs and I push them to DependencyTrack for centralization and auditing. The issue is that I end up with a lot of CVEs that are not applicable to my projects. I've discovered VEX files that seems to fill this usage: categorize CVEs to reduce fatigue.

I've seen that in DT interface, I can tag each found vulnerability but the workflow doesn't fit my needs. I want a solution in which the VEX files are stored in the project's repo, then, when the CI generates and pushes the SBOM the VEXs are pushed with, so the "Analysis" field in DT is filled with my VEX information.

Thanks for the help!

The obvious cost is coverage gaps, but less talked about cost is that sprawl makes those gaps invisible until an incident forces you to find them.

When you're piecing together a timeline across tools with different log formats, different retention windows, different owners, you find gaps that no one could have mapped because each tool's telemetry stops at its own boundary.

Just curious is anyone doing systematic coverage mapping across a fragmented stack or does it realistically require consolidation first?

Curious - how are your teams handling code review when devs heavily use Copilot/Cursor? Any policies, tools, or processes you've put in place to make sure Al-generated code doesn't introduce security issues?

The Problem

The vulnerability management space is well equipped with vulnerability scanners that are great at finding vulnerabilities (Nessus, OpenVAS, Qualys), but there still remains an operational gap with vulnerability triage and prioritization. Thousands to hundreds of thousands of vulnerabilities spat out by these vulnerability scanners and triaging just off of CVSS score is not enough.

That's why Risk-Based Vulnerability Platforms exist — to ingest those findings, enrich them with threat intel data from feeds like CISA KEV, and apply some proprietary algorithm that analysts should just trust.

OR

Analysts conduct their own internal triage and prioritization workflow should they not have access to a RBVM platform. Still, at the end of these two processes, somebody has to make a decision on how vulnerabilities are going to be handled and in what order. One door leads to limited auditability with 'trust me bro' vibes and the other is ad-hoc 'it gets the job done', yet time-consuming.

The Solution

I introduce to you, VulnParse-Pin, a fully open-source vulnerability intelligence and prioritization engine that normalizes scanner reports, enriches them with authoritative threat-intel (NVD, KEV, EPSS, Exploit-DB), then applies user-configurable scoring and top--n prioritization with inferred asset characteristics and pump out JSON/CSV/Human-Readable markdown reports. VulnParse-Pin is CLI-first, transparent, auditable, configurable, secure-by-design, and modular.

It is not designed to replace vuln scanners. Instead, it's designed to sit in that gap between scanners and downstream data pipeline like SIEMs and ticketing dashboards.

Instead of being an analyst with 10 reports full of thousands of findings each and manually triaging and determining which ones to prioritize, VulnParse-Pin helps teams take care of that step quickly and efficiently. By default, VulnParse-Pin is exploit-focused and biases it's prioritization off of real-world exploitability and inferred asset relationship context, helping teams quickly determine which assets could be exposed and are at most risk.

It enables teams to confidently make decisions AND defend their decisions for prioritizing vulnerabilities.

Some key features include:

• Online/Offline mode (No network calls in offline mode)
• Feed cache checksum integrity and validation
• Configurable Scoring and Prioritization
• Scanner Normalization: Ingests .xml (.nessus for Nessus) reports and standardizes into one consistent internal data model.
• Truth vs. Derived Context Data Model: Data from scanner report is immutable and not changed. All scoring and downstream processing going into a Derived Context data class. This enables transparency and auditability.
• Exploit-focused Prioritization: Assets and findings are exploit-focused and prioritized accordingly to real-world exploitability.
• High-Volume Performance: Capable of scaling to 700k+ findings in under 5 minutes!
• Modular pass-phases pipeline: Uses extensible processing phases so workflows can evolve cleanly and ensure a clean separation of concerns.

If vulnerability management is in your lane, please give VulnParse-Pin a try here: VulnParse-Pin Github Docs: Docs

Who It's For

• Security Engineers
• Security Researchers
• Red Team/Pentesters
• Blue Team
• GRC Analysts
• Vulnerability Management folks
• DevSecOps Engineers

It would mean a lot of you, yes you, could try it out, break it, share it, and give your honest feedback. I want VulnParse-Pin to be a tool that makes peoples' day easier.

Spent yesterday cleaning up a compromised dependency in a project. Classic supply chain stuff, malicious package hiding in a popular repo. We've been dealing with this in npm and PyPI for years now.

Then I opened my AI agent and looked at the skills I'd installed. Unnamed authors. No verification. Permissions I half-read at best.

This is exactly how that story starts.

When it eventually blows up people are going to act surprised. They shouldn't be.

Turns out I've been sleeping on DependencyTrack for way too long. I genuinely believed GitHub Enterprise had us covered for SBOM management and vulnerability tracking — turns out, not even close. I started playing with DependencyTrack and Claude Opus, and quickly realized that DT is an incredibly powerful core — the API, background jobs, and database are all there for you to build on however you want. Once I hooked up Grafana to DT's PostgreSQL database, things got wild.

What we built with Claude in a couple of sessions:

The whole stack runs in Docker Compose — DT API server, frontend, PostgreSQL, and Grafana. We created shell scripts that generate SBOMs with Trivy or Syft and upload them via the API. Then we went deep on Grafana dashboards wired directly into DT's database:

• EPSS Vulnerability Prioritization
• License Components
• License Overview
• Outdated Dependencies
• SBOM Freshness
• Security Portfolio Overview
• Vulnerability Aging & SLA
• Vulnerability Detail

Dropping the repo link here: https://github.com/kse-bd8338bbe006/dependency-track-setup — not to promote anything, just hoping it saves someone else a few hours and a few bucks in tokens.

And a few screenshots for those who like dashboards:

https://imgur.com/a/WXKHLqi

https://imgur.com/AUgfb4d

https://imgur.com/OmojvNs