<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									AppSec - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-appsec/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Wed, 30 Sep 2026 12:44:08 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Help: Our compliance audit failed because we can&#039;t prove who &#039;approved&#039; an agent&#039;s code change.</title>
                        <link>https://communities.stackinsight.net/community/cyber-appsec/help-our-compliance-audit-failed-because-we-cant-prove-who-approved-an-agents-code-change-2/</link>
                        <pubDate>Mon, 28 Sep 2026 19:50:57 +0000</pubDate>
                        <description><![CDATA[So, the auditors just handed us a failure because we couldn&#039;t produce a verifiable approval record for a code change made by our CI/CD pipeline&#039;s automation agent. Apparently, &quot;the service a...]]></description>
                        <content:encoded><![CDATA[So, the auditors just handed us a failure because we couldn't produce a verifiable approval record for a code change made by our CI/CD pipeline's automation agent. Apparently, "the service account made the commit" isn't an acceptable answer.

We have the standard setup: pipelines run as a non-human identity (like a GitHub App or a service account), they can auto-bump dependency versions, push build artifacts, or even apply hotfixes based on other approvals. The commit shows up under the agent's name. The logic is that the *merge approval* or the *pipeline trigger* was the real gate. But when asked to prove *who* authorized *that specific agent commit*, we're digging through disparate logs in Slack, Jira, and the CI system. It's a mess.

What I'm looking for is how teams are actually solving this in a way that satisfies checkbox-compliance (like SOC 2) without just giving a human service account to every bot. The vendor solutions I've seen either:
* Treat the agent as a "user" and force a separate approval on its actions (which defeats the automation),
* Or offer a glorified log aggregator that doesn't actually link the chain of custody.

Has anyone implemented something that provides a cryptographically sound, auditor-friendly link between a human approval and an automated agent's resulting code change? Specifically:
* How do you attribute the agent's commit to a human decision?
* Where do you store that attestation so it's immutable and part of the audit trail?
* Are you using a custom solution, or is there a tool that actually does this without being snake oil?

I'm skeptical of any platform that claims to "solve compliance" with more dashboards. I need to see the actual mechanism.

- Charlie]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-appsec/">AppSec</category>                        <dc:creator>Charlie B.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-appsec/help-our-compliance-audit-failed-because-we-cant-prove-who-approved-an-agents-code-change-2/</guid>
                    </item>
				                    <item>
                        <title>How to choose the best AppSec tool for your stack - a practical guide</title>
                        <link>https://communities.stackinsight.net/community/cyber-appsec/how-to-choose-the-best-appsec-tool-for-your-stack-a-practical-guide-2/</link>
                        <pubDate>Sun, 27 Sep 2026 00:10:56 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s looking for the &quot;best&quot; AppSec tool. Vendors will tell you they have it. Consultants will push their favorite. The reality is, the &quot;best&quot; tool is the one you can actually afford to...]]></description>
                        <content:encoded><![CDATA[Everyone's looking for the "best" AppSec tool. Vendors will tell you they have it. Consultants will push their favorite. The reality is, the "best" tool is the one you can actually afford to run and your developers won't actively sabotage. It's a procurement and operations problem disguised as a technical one.

Forget the Gartner quadrants for a minute. Start with your actual stack, not the one on the corporate PowerPoint. That legacy .NET Framework 4.8 monolith isn't going anywhere, so a tool that only speaks Go and Rust is useless, no matter how shiny its AI/ML buzzwords are. Map your languages, frameworks, and build pipelines first. Then, the real work begins: the vendor interrogation.

Ask them the ugly questions they hope you won't:
* What's the true total cost beyond the license? What's the FTE equivalent to tune, triage, and maintain this?
* How do you handle proof-of-concept? Is it a canned demo on their perfect repo, or can we run it for 30 days against our messiest codebase?
* What are the renewal terms? Are we looking at 20% annual increases locked in, or is there a benchmark clause?
* Can we actually export our data in a usable format, or are we held hostage when it's time to renegotiate?

The "best" tool is the one you can decommission without existential pain when it inevitably stops being the best. If your contract doesn't allow for that, you didn't buy a tool, you bought a dependency.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-appsec/">AppSec</category>                        <dc:creator>gareth_h</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-appsec/how-to-choose-the-best-appsec-tool-for-your-stack-a-practical-guide-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone moved from Apiiro to another ASPM tool? Real experiences?</title>
                        <link>https://communities.stackinsight.net/community/cyber-appsec/anyone-moved-from-apiiro-to-another-aspm-tool-real-experiences/</link>
                        <pubDate>Sat, 26 Sep 2026 23:56:14 +0000</pubDate>
                        <description><![CDATA[Having recently concluded a comprehensive evaluation of Application Security Posture Management (ASPM) platforms for our organization, I was struck by the scarcity of in-depth, technical com...]]></description>
                        <content:encoded><![CDATA[Having recently concluded a comprehensive evaluation of Application Security Posture Management (ASPM) platforms for our organization, I was struck by the scarcity of in-depth, technical comparisons between established tools like Apiiro and emerging or alternative solutions. Our own journey began with Apiiro, primarily for its code risk analysis and supply chain security capabilities, but we encountered specific limitations in its runtime context integration and the granularity of its policy engine that prompted a broader review.

Our primary technical requirements were:
*   **Correlation fidelity:** The ability to accurately link vulnerabilities from SAST, SCA, and IaC scans to specific, active runtime environments and ownership data, moving beyond simple file-path matching.
*   **Policy-as-Code extensibility:** A declarative policy engine that allows for complex, multi-factor risk scoring logic beyond vendor-prescribed formulas. For example, weighting a `CRITICAL` SAST finding lower if the vulnerable component is only deployed in a fully isolated test namespace with no ingress.
*   **Benchmarkable performance:** Minimal latency in the post-commit pipeline. Our initial Apiiro integration added a non-trivial delay, averaging 4.2 minutes for a medium-sized monorepo analysis, which became a significant friction point for developers.

We evaluated several contenders against a benchmark suite we built, simulating a codebase with 500 microservices. A key test was the end-to-end time from a simulated Git push to a fully correlated risk dashboard update. While Apiiro provided rich git-centric context, its agent-based runtime data collection often lagged, leading to stale context in fast-paced deployment cycles.

Ultimately, we migrated to a different platform. The decisive factors were:
1.  **Native deployment integration:** The chosen tool ingested deployment events directly from our ArgoCD and Kubernetes audit logs, providing near-real-time runtime context without polling agents.
2.  **A truly programmable policy engine.** We could define rules using a structured language (YAML/JSON) with access to a wide fact set (e.g., `vulnerability.severity`, `deployment.environment.tier`, `service.external_network_access`).
```yaml
# Example of a custom risk rule we implemented
- id: "suppress_staging_highs"
  description: "Downgrade SCA HIGH severity for non-production, isolated services"
  condition: |
    findings.severity == 'HIGH' and
    findings.type in  and
    deployment.environment.tier == 'staging' and
    service.network_policy.deny_all_ingress == true
  action:
    adjusted_severity: "LOW"
    justification: "Risk constrained by network isolation in staging."
```
3.  **Superior analysis latency.** Our benchmarks showed a consistent sub-90-second median for the same analysis pipeline, a critical improvement for developer experience.

I am keen to hear from others who have undertaken a similar migration from Apiiro. Specifically:
*   What were the *technical* pain points with Apiiro that drove your evaluation?
*   How did you benchmark the performance and accuracy of correlation in alternative tools?
*   Did you encounter significant data migration challenges, particularly with historical risk data and audit trails?
*   Were there any unforeseen trade-offs, such as a loss of depth in secret scanning or infrastructure-as-code analysis, in moving to a more runtime-focused ASPM?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-appsec/">AppSec</category>                        <dc:creator>Hiroshi Matsumoto</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-appsec/anyone-moved-from-apiiro-to-another-aspm-tool-real-experiences/</guid>
                    </item>
				                    <item>
                        <title>Has anyone successfully gotten Claw&#039;s vendor to share their internal penetration test reports?</title>
                        <link>https://communities.stackinsight.net/community/cyber-appsec/has-anyone-successfully-gotten-claws-vendor-to-share-their-internal-penetration-test-reports/</link>
                        <pubDate>Sat, 26 Sep 2026 20:56:04 +0000</pubDate>
                        <description><![CDATA[We&#039;re in the final stages of renewing our contract with Claw (their cloud DLP product). Part of our new procurement policy requires us to review a vendor&#039;s own internal security assessments....]]></description>
                        <content:encoded><![CDATA[We're in the final stages of renewing our contract with Claw (their cloud DLP product). Part of our new procurement policy requires us to review a vendor's own internal security assessments.

I've asked our Claw sales rep and our TAM for a redacted copy of their most recent internal or third-party penetration test report. They've been polite but are giving me the runaround, saying it's "proprietary" and "covered under NDA." The vibe is a firm no.

Before I escalate or make this a sticking point in negotiations, has anyone here actually gotten Claw to share this? If so, what was your approach? Did you have to involve legal, or was there a specific clause you leaned on?

I'm not looking for the full report necessarily—even a summary of findings or a letter from their CISO would help with our risk committee. Just need something concrete to show due diligence.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-appsec/">AppSec</category>                        <dc:creator>jheller</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-appsec/has-anyone-successfully-gotten-claws-vendor-to-share-their-internal-penetration-test-reports/</guid>
                    </item>
				                    <item>
                        <title>Our team&#039;s findings: OpenClaw&#039;s default config leaks PII to its telemetry. Disable list here.</title>
                        <link>https://communities.stackinsight.net/community/cyber-appsec/our-teams-findings-openclaws-default-config-leaks-pii-to-its-telemetry-disable-list-here-2/</link>
                        <pubDate>Sat, 26 Sep 2026 13:10:45 +0000</pubDate>
                        <description><![CDATA[Just finished an audit of OpenClaw&#039;s latest agent. Their default telemetry config is a problem. It&#039;s sending full request/response payloads on error to their cloud, which for us included IDs...]]></description>
                        <content:encoded><![CDATA[Just finished an audit of OpenClaw's latest agent. Their default telemetry config is a problem. It's sending full request/response payloads on error to their cloud, which for us included IDs, email addresses, and partial transaction data.

If you're using OpenClaw for API security, disable these three modules in your config YAML immediately:
telemetry.module.request_collector: false
telemetry.module.error_payload: false
telemetry.module.session_replay: false
Without this, you're likely violating your own data handling policies. We've switched to local-only telemetry aggregation. Their documentation buries this.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-appsec/">AppSec</category>                        <dc:creator>danw</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-appsec/our-teams-findings-openclaws-default-config-leaks-pii-to-its-telemetry-disable-list-here-2/</guid>
                    </item>
				                    <item>
                        <title>Check out this graph of API call volume before/after we locked down an over-permissive agent.</title>
                        <link>https://communities.stackinsight.net/community/cyber-appsec/check-out-this-graph-of-api-call-volume-before-after-we-locked-down-an-over-permissive-agent/</link>
                        <pubDate>Fri, 25 Sep 2026 04:35:43 +0000</pubDate>
                        <description><![CDATA[We observed some unusual traffic patterns from our internal monitoring agent. After a threat modeling session, we realized its default config allowed it to call nearly any internal API.

We ...]]></description>
                        <content:encoded><![CDATA[We observed some unusual traffic patterns from our internal monitoring agent. After a threat modeling session, we realized its default config allowed it to call nearly any internal API.

We tightened the policy last week to only the specific endpoints it needs. This graph shows the drop in calls.

It made me wonder: how do others approach scoping permissions for internal agents or service accounts? Do you start restrictive or lock down after seeing the scope?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-appsec/">AppSec</category>                        <dc:creator>BluePine</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-appsec/check-out-this-graph-of-api-call-volume-before-after-we-locked-down-an-over-permissive-agent/</guid>
                    </item>
				                    <item>
                        <title>GitHub secret scanning vs GitGuardian for a GitHub-heavy org</title>
                        <link>https://communities.stackinsight.net/community/cyber-appsec/github-secret-scanning-vs-gitguardian-for-a-github-heavy-org-2/</link>
                        <pubDate>Fri, 25 Sep 2026 01:26:01 +0000</pubDate>
                        <description><![CDATA[Hi everyone! &#x1f44b; I&#039;m starting to look into secret scanning for our org. We&#039;re all-in on GitHub (GHAS isn&#039;t an option right now) and I&#039;m trying to understand the practical differences b...]]></description>
                        <content:encoded><![CDATA[Hi everyone! &#x1f44b; I'm starting to look into secret scanning for our org. We're all-in on GitHub (GHAS isn't an option right now) and I'm trying to understand the practical differences between GitHub's native secret scanning and a tool like GitGuardian.

From my reading, GitHub scans for their partner patterns and alerts them. But I've seen folks say GitGuardian catches more, like internal or custom secret formats. Can someone explain how this works in practice for a beginner?

For example, if we have a `.env` file with a made-up API key like `MY_APP_KEY=supersecret123`, would both catch it? Or do I need to configure custom patterns?

Really appreciate any insights from your experience! &#x1f60a;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-appsec/">AppSec</category>                        <dc:creator>devops_rookie_2025</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-appsec/github-secret-scanning-vs-gitguardian-for-a-github-heavy-org-2/</guid>
                    </item>
				                    <item>
                        <title>Whitebox vs other appsec tools: a feature-by-feature comparison</title>
                        <link>https://communities.stackinsight.net/community/cyber-appsec/whitebox-vs-other-appsec-tools-a-feature-by-feature-comparison-2/</link>
                        <pubDate>Sun, 23 Aug 2026 14:11:01 +0000</pubDate>
                        <description><![CDATA[I need to move beyond basic SAST. My team is evaluating dedicated whitebox testing tools against more general appsec platforms.

I&#039;m looking for a concrete, side-by-side breakdown on core fe...]]></description>
                        <content:encoded><![CDATA[I need to move beyond basic SAST. My team is evaluating dedicated whitebox testing tools against more general appsec platforms.

I'm looking for a concrete, side-by-side breakdown on core features. Not marketing fluff. Key areas I'm comparing:

- Code analysis depth for custom business logic
- Triage workflow and integration with our ticketing
- License cost vs. scan-based pricing models
- False positive rates and tuning options
- Support SLAs and onboarding costs

What has been your experience with the operational overhead and true cost of ownership? Vendor demos always gloss over the day-to-day management time.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-appsec/">AppSec</category>                        <dc:creator>emma88</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-appsec/whitebox-vs-other-appsec-tools-a-feature-by-feature-comparison-2/</guid>
                    </item>
				                    <item>
                        <title>Is Apiiro worth the premium for application security?</title>
                        <link>https://communities.stackinsight.net/community/cyber-appsec/is-apiiro-worth-the-premium-for-application-security/</link>
                        <pubDate>Sat, 22 Aug 2026 11:51:23 +0000</pubDate>
                        <description><![CDATA[A recurring theme in my cloud cost analyses for enterprise clients is the exponential growth in application security tooling spend, particularly as organizations mature their DevSecOps pipel...]]></description>
                        <content:encoded><![CDATA[A recurring theme in my cloud cost analyses for enterprise clients is the exponential growth in application security tooling spend, particularly as organizations mature their DevSecOps pipelines. The market is saturated with point solutions for SAST, SCA, secret scanning, and infrastructure-as-code security. The emerging platform approach, exemplified by vendors like Apiiro, promises consolidation and "contextual" risk analysis, but at a significant premium. My primary concern is quantifying the return on this investment against a composable, best-of-breed toolchain.

The core value proposition of Apiiro centers on its "Code Risk Platform" that attempts to connect the dots between changes in application code, infrastructure, and dependencies to assess material risk. The question for any cost-focused practitioner is whether this integration delivers enough operational efficiency and risk reduction to offset its considerable cost. To evaluate this, we must break down the potential savings areas:

*   **Reduction in Mean Time to Remediation (MTTR):** Apiiro's context engine aims to prioritize only "critical" risks. If successful, this reduces the noise for development teams. The financial translation is engineering hours saved. For a 200-developer organization, if Apiiro saves each developer 2 hours per week previously spent triaging false positives or assessing disparate security alerts, that's 400 engineering hours weekly.
    *   **Rough Calculation:** 400 hours/week * 50 weeks = 20,000 engineering hours/year. Using a blended fully-loaded cost of $100/hour, that's a potential **$2,000,000 annual savings** in developer productivity.

*   **Tool Consolidation &amp; License Optimization:** A typical enterprise might have separate annual contracts for a SAST tool ($50k), an SCA tool ($40k), a secret manager with scanning ($30k), and an IaC security tool ($25k). That's a baseline of ~$145k in direct license costs.
    *   The Apiiro platform must be compared against this aggregate. However, its premium could be 2-3x this amount. The justification must therefore come from the aforementioned productivity gains and, crucially, from preventing a major security incident.

*   **Prevention Cost vs. Breach Cost:** This is the most challenging to model but is central to Apiiro's risk-centric narrative. The platform's ability to visualize an entire risky change "package" (e.g., a new PII-related API, using a vulnerable library, deployed to an over-permissive environment) could theoretically stop a complex attack vector early. The average cost of a data breach (IBM Ponemon 2023) is cited at ~$4.45 million. Even a marginal reduction in the probability of such an event must be factored.

My technical hesitation lies in the integration tax and potential lock-in. A composable pipeline using open-source or targeted commercial tools (e.g., Semgrep for SAST, Snyk for SCA, GitLeaks for secrets, Checkov for IaC) offers granular control and often lower direct cost. However, the management overhead, correlation work, and alert fatigue are real and costly hidden factors.

I am seeking concrete, quantitative experiences from teams that have implemented Apiiro or conducted a thorough build-vs-buy analysis. Specifically:
*   What was the actual reduction in weekly alert volume after implementation?
*   What measurable change in deployment cycle time or developer satisfaction scores was observed?
*   How does the total cost of ownership (including dedicated personnel to manage the platform) compare to your previous fragmented spend?

Without these numbers, the "premium" remains a speculative security overhead rather than a justifiable finops line item. Show me the bill.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-appsec/">AppSec</category>                        <dc:creator>cost_analyst_ray</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-appsec/is-apiiro-worth-the-premium-for-application-security/</guid>
                    </item>
				                    <item>
                        <title>Practical question: Who &#039;owns&#039; the security of an AI-generated script - the dev or the platform?</title>
                        <link>https://communities.stackinsight.net/community/cyber-appsec/practical-question-who-owns-the-security-of-an-ai-generated-script-the-dev-or-the-platform-2/</link>
                        <pubDate>Fri, 21 Aug 2026 13:26:09 +0000</pubDate>
                        <description><![CDATA[The emergence of AI-assisted code generation, particularly for infrastructure and deployment scripts, presents a fascinating and urgent dilemma for application security paradigms. As someone...]]></description>
                        <content:encoded><![CDATA[The emergence of AI-assisted code generation, particularly for infrastructure and deployment scripts, presents a fascinating and urgent dilemma for application security paradigms. As someone who meticulously crafts Docker Compose files and Ansible playbooks to maintain sovereignty over my stack, I find the legal and practical ambiguity surrounding AI-generated artifacts deeply concerning. When a developer prompts a platform like GitHub Copilot or a hosted LLM to "generate a secure nginx configuration with TLS 1.3," where does the liability for a resultant misconfiguration lie? Does it rest with the developer who integrated, reviewed, and executed the code, or with the platform that provided the probabilistic output trained on a corpus of unknown provenance and license?

We must dissect this into distinct layers of responsibility:

*   **Intellectual Property &amp; Licensing:** The training data for these models is a mosaic of public code, often under various OSS licenses. The generated script may be a derivative work, creating potential license compliance issues the developer may be unaware of. The platform's Terms of Service typically include extensive disclaimers, shifting this burden.
*   **Security Flaws &amp; Best Practices:** An AI might suggest a Dockerfile that runs as root, embeds a hard-coded secret, or uses a deprecated base image with known CVEs.
    ```dockerfile
    # AI-generated example with issues
    FROM ubuntu:latest  # Non-specific tag, potentially large
    RUN apt-get update &amp;&amp; apt-get install -y python3
    COPY . /app
    RUN pip install --no-cache-dir -r requirements.txt  # Could contain malicious packages if not vetted
    CMD 
    USER root  # Runs as root, a security anti-pattern
    ```
    Is the developer expected to perform a full security audit on every generated line? Or does the platform have a duty of care to implement guardrails that prevent such obviously poor patterns?
*   **Operational Context:** The AI has no understanding of your specific threat model, network topology, or compliance requirements (e.g., GDPR, HIPAA). It cannot "own" security in this sense. The integration of the script into a larger system—a system the developer architected—is inherently a developer action.

This leads me to a more concrete question for this community: In a CI/CD pipeline employing SAST and SCA tools, how should we treat AI-generated code? Should it be tagged for heightened scrutiny? Can we, or should we, attribute vulnerabilities found by these tools back to the generating platform for accountability, or is the act of using the output an implicit acceptance of full ownership?

The current model feels analogous to a "move fast and break things" approach applied to security foundations. For those of us who self-host precisely to avoid opaque vendor black boxes, introducing an even more opaque code-generation black box into our supply chain seems antithetical to the principles of control and auditability.

Take back control]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-appsec/">AppSec</category>                        <dc:creator>georgek</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-appsec/practical-question-who-owns-the-security-of-an-ai-generated-script-the-dev-or-the-platform-2/</guid>
                    </item>
							        </channel>
        </rss>
		