<?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>
									Veracode Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-veracode/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Thu, 23 Jul 2026 02:15:35 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Am I the only one who thinks the reporting is stuck in 2010?</title>
                        <link>https://communities.stackinsight.net/community/cyber-veracode/am-i-the-only-one-who-thinks-the-reporting-is-stuck-in-2010/</link>
                        <pubDate>Tue, 21 Jul 2026 21:03:11 +0000</pubDate>
                        <description><![CDATA[Just tried to pull a simple report from Veracode. Had to export three different CSV files and manually join them in a spreadsheet. In 2024.

Their API is marginally better, but you still nee...]]></description>
                        <content:encoded><![CDATA[Just tried to pull a simple report from Veracode. Had to export three different CSV files and manually join them in a spreadsheet. In 2024.

Their API is marginally better, but you still need to write a small script to get data into a usable format. Why isn't there a sane, consolidated JSON output by default? Feels like they've poured everything into the scanner and left reporting as an afterthought.

```bash
# This shouldn't be necessary
curl -s --header "Authorization: bearer $TOKEN" "https://api.veracode.com/appsec/v1/applications" &gt; apps.json
curl -s --header "Authorization: bearer $TOKEN" "https://api.veracode.com/appsec/v2/applications/$APP_ID/findings" &gt; findings.json
# Now go reconcile the two.
```

If you want a trend line or a basic dashboard, you're building it yourself. For a tool at this price point, that's a joke.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-veracode/">Veracode Reviews</category>                        <dc:creator>devops_contrarian_42</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-veracode/am-i-the-only-one-who-thinks-the-reporting-is-stuck-in-2010/</guid>
                    </item>
				                    <item>
                        <title>Has anyone tried the Veracode AI feature? Is it just glorified pattern matching?</title>
                        <link>https://communities.stackinsight.net/community/cyber-veracode/has-anyone-tried-the-veracode-ai-feature-is-it-just-glorified-pattern-matching/</link>
                        <pubDate>Tue, 21 Jul 2026 19:51:41 +0000</pubDate>
                        <description><![CDATA[The hype suggests it can reason about code. What if it&#039;s just a more expensive regex engine?

I&#039;m looking at the audit trail, wondering what exactly I&#039;m paying for. Is the &#039;AI&#039; flag just a m...]]></description>
                        <content:encoded><![CDATA[The hype suggests it can reason about code. What if it's just a more expensive regex engine?

I'm looking at the audit trail, wondering what exactly I'm paying for. Is the 'AI' flag just a marketing wrapper on static analysis rules they already had? Anyone seen it catch something genuinely novel, or is the main feature a higher false-positive bill?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-veracode/">Veracode Reviews</category>                        <dc:creator>henryp</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-veracode/has-anyone-tried-the-veracode-ai-feature-is-it-just-glorified-pattern-matching/</guid>
                    </item>
				                    <item>
                        <title>Veracode vs GitLab SAST for a 50-person IoT team with C/C++</title>
                        <link>https://communities.stackinsight.net/community/cyber-veracode/veracode-vs-gitlab-sast-for-a-50-person-iot-team-with-c-c/</link>
                        <pubDate>Tue, 21 Jul 2026 19:26:07 +0000</pubDate>
                        <description><![CDATA[Hey folks! &#x1f44b; I&#039;ve been deep in the weeds lately evaluating SAST tools for our IoT shop, and I figured I&#039;d share my findings. We&#039;re a 50-person team primarily writing C and C++ for em...]]></description>
                        <content:encoded><![CDATA[Hey folks! &#x1f44b; I've been deep in the weeds lately evaluating SAST tools for our IoT shop, and I figured I'd share my findings. We're a 50-person team primarily writing C and C++ for embedded devices, and our security review process needed a serious upgrade. The two main contenders we looked at were **Veracode** (specifically their static analysis offering) and **GitLab's built-in SAST** (leveraging Semgrep and others). We ran both through their paces on a few of our codebases, and I wanted to break down the integration and workflow implications for a team like ours.

**Here’s the detailed breakdown from an integration and daily use perspective:**

*   **Integration &amp; Automation Workflow:**
    *   **GitLab SAST:** This was a huge draw. Since we already use GitLab for source control and CI/CD, adding the SAST check was a matter of adding a template include in our `.gitlab-ci.yml`. The scanning happens as a job in the pipeline. It's incredibly straightforward for getting quick feedback in a merge request.
    ```yaml
    # Example snippet from our .gitlab-ci.yml
    include:
      - template: Security/SAST.gitlab-ci.yml

    # We then customize the stage and variables for our C++ builds
    sast:
      variables:
        SAST_EXCLUDED_PATHS: "third_party, test"
        SCAN_KUBERNETES_MANIFESTS: "false"
    ```
    *   **Veracode:** Requires a more "outside-in" integration. We used their CLI tool (`veracode`) to upload code to their platform via API. This means adding a dedicated step in our CI to package and push the code. It's not *hard*, but it's an extra layer. The upside is scanning happens on their servers, so no resource hit on our runners.

*   **C/C++ Support &amp; Findings Detail:**
    *   **Veracode:** Felt more mature for our core languages. The findings were detailed, with good explanations and often included CWE mappings and remediation guidance specific to memory management, buffer overflows, and integer overflows—our daily bread and butter. The ability to get a PDF report for audit purposes was a plus.
    *   **GitLab SAST:** It works, but the findings can feel more generic. For C/C++, it leans heavily on Semgrep rules and Flawfinder. It's great for catching obvious issues early, but we found we needed to fine-tune the rules more to reduce false positives on our low-level code. The findings are integrated directly into the merge request UI, which is fantastic for developer visibility.

*   **The Middleware &amp; Data Sync Angle (My Jam!):**
    This was a big differentiator for us. With **GitLab**, the findings live right in GitLab. You can use its internal status checks or webhooks to block merges. With **Veracode**, the data lives in their cloud portal. To make those findings actionable in *our* workflow (like creating Jira tickets or Slack alerts), we had to build a small middleware layer using **Make**.
    We set up a webhook from Veracode that triggers a scenario whenever a new scan finishes. It parses the JSON, filters for critical/high flaws, and then either posts to a dedicated Slack channel or creates a ticket.
    ```javascript
    // A simplified look at the webhook payload we process:
    {
      "scan_id": "12345",
      "scan_status": "completed",
      "results_summary": {
        "total_flaws": 42,
        "flaws_severity_5": 3,
        "flaws_severity_4": 12
      }
      // ... more data
    }
    ```
    This extra automation step is powerful but adds initial setup complexity compared to GitLab's all-in-one view.

*   **Pricing &amp; Scaling Gotchas:**
    *   **GitLab SAST:** It's "free" if you're on a high-enough GitLab tier (Ultimate). For a 50-person team, the per-user licensing cost of GitLab Ultimate vs. adding a separate tool becomes a key question. The cost is bundled.
    *   **Veracode:** Traditional per-application/per-scan pricing model. It can become significant as you scale the number of codebases and scan frequency. For us, the value hinged on the depth of analysis justifying the separate line item.

**My Takeaway for an IoT Team:**
If you are **all-in on GitLab** and want a seamless, "shift-left" experience that gets developers looking at security findings without leaving their workflow, GitLab SAST is a compelling, low-friction choice. However, if you need **deep, audit-ready analysis** of C/C++ and don't mind managing a separate integration point (and potentially building some automation bridges), Veracode provides more robust, specialized results.

We're still finalizing our decision, but leaning towards Veracode for the depth, and accepting the integration overhead. I'd love to hear if anyone else in a similar embedded space has walked this path and what your automation bridges look like!

-- Ian]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-veracode/">Veracode Reviews</category>                        <dc:creator>Integration Ian</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-veracode/veracode-vs-gitlab-sast-for-a-50-person-iot-team-with-c-c/</guid>
                    </item>
				                    <item>
                        <title>Moved from SonarQube to Veracode for compliance - pitfalls after 1 year</title>
                        <link>https://communities.stackinsight.net/community/cyber-veracode/moved-from-sonarqube-to-veracode-for-compliance-pitfalls-after-1-year/</link>
                        <pubDate>Tue, 21 Jul 2026 14:38:46 +0000</pubDate>
                        <description><![CDATA[We switched to Veracode for FedRAMP compliance requirements. After one year, the compliance box is checked but our developer velocity took a hit.

The main pitfall is the scan time for large...]]></description>
                        <content:encoded><![CDATA[We switched to Veracode for FedRAMP compliance requirements. After one year, the compliance box is checked but our developer velocity took a hit.

The main pitfall is the scan time for large apps. A full scan can take hours, which breaks CI/CD flow. We had to reconfigure pipelines to use pipeline scans on PRs and schedule full scans overnight. The false positive rate is also higher than SonarQube, leading to developer frustration and wasted time triaging. The SAST rules are rigid and the remediation advice is often generic. Vendor support response times slowed down after the initial onboarding period. The cost is significant, and the pricing model feels opaque when scaling to more applications.

Looking for practical workarounds others have found, especially on scan optimization and reducing noise. Also, how are you handling container scanning? Their Greenlight IDE plugin is decent but doesn't fully offset the pipeline delays.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-veracode/">Veracode Reviews</category>                        <dc:creator>adams</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-veracode/moved-from-sonarqube-to-veracode-for-compliance-pitfalls-after-1-year/</guid>
                    </item>
				                    <item>
                        <title>Dynamic scan authentication with OAuth2 is a nightmare. Anyone solved it?</title>
                        <link>https://communities.stackinsight.net/community/cyber-veracode/dynamic-scan-authentication-with-oauth2-is-a-nightmare-anyone-solved-it/</link>
                        <pubDate>Tue, 21 Jul 2026 12:55:45 +0000</pubDate>
                        <description><![CDATA[Just spent three days trying to get Veracode Dynamic Analysis to authenticate through an OAuth2 flow for a modern SPA backend. The documentation reads like it was written for a world where e...]]></description>
                        <content:encoded><![CDATA[Just spent three days trying to get Veracode Dynamic Analysis to authenticate through an OAuth2 flow for a modern SPA backend. The documentation reads like it was written for a world where every app still uses HTTP Basic Auth.

The core issue? Their scanner seems to treat OAuth2 as a single-step "login," not as the multi-stage handshake it actually is. Capturing the token exchange via proxy is one thing, but getting the scanner to correctly replay the sequence, handle redirects to the identity provider, and manage the session cookies thereafter? Good luck.

Has anyone actually made this work without building a custom, stateful proxy server to sit in the middle? I'm looking for concrete steps, not theoretical "it should work" replies.

*   Did you have to pre-authenticate and hard-code a bearer token (defeating the point of testing the auth flow itself)?
*   Was the key to manipulating the `veracode_username` and `veracode_password` fields in the XML config to somehow trigger the right POSTs?
*   Any specific order of operations in the "Authentication Script" that finally got the tokens refreshed?

Our team's FinOps side is already groaning at the engineering hours burned on this. There's a real cost to tools that make standard modern auth protocols feel like a bespoke integration project.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-veracode/">Veracode Reviews</category>                        <dc:creator>cloud_cost_fighter</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-veracode/dynamic-scan-authentication-with-oauth2-is-a-nightmare-anyone-solved-it/</guid>
                    </item>
				                    <item>
                        <title>Troubleshooting: Greenlight not showing results in IntelliJ</title>
                        <link>https://communities.stackinsight.net/community/cyber-veracode/troubleshooting-greenlight-not-showing-results-in-intellij/</link>
                        <pubDate>Tue, 21 Jul 2026 12:07:35 +0000</pubDate>
                        <description><![CDATA[Greenlight scan completes but the Veracode panel in IntelliJ stays empty. No findings shown.

I&#039;ve verified my API credentials and connection. The scan log shows no errors. This happens with...]]></description>
                        <content:encoded><![CDATA[Greenlight scan completes but the Veracode panel in IntelliJ stays empty. No findings shown.

I've verified my API credentials and connection. The scan log shows no errors. This happens with both new and existing projects. Is there a known configuration step missing? I need the results directly in the IDE.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-veracode/">Veracode Reviews</category>                        <dc:creator>adams</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-veracode/troubleshooting-greenlight-not-showing-results-in-intellij/</guid>
                    </item>
				                    <item>
                        <title>Hot take: Their marketing claims about speed don&#039;t match our 45-minute scans.</title>
                        <link>https://communities.stackinsight.net/community/cyber-veracode/hot-take-their-marketing-claims-about-speed-dont-match-our-45-minute-scans/</link>
                        <pubDate>Tue, 21 Jul 2026 11:20:43 +0000</pubDate>
                        <description><![CDATA[We’re evaluating Veracode SAST. Their messaging emphasizes fast, incremental scanning integrated into the pipeline.

Our reality:
- Baseline scan for a ~500k LOC Java monolith took 4.5 hours...]]></description>
                        <content:encoded><![CDATA[We’re evaluating Veracode SAST. Their messaging emphasizes fast, incremental scanning integrated into the pipeline.

Our reality:
- Baseline scan for a ~500k LOC Java monolith took 4.5 hours. Acceptable.
- Subsequent “incremental” scans on a typical PR (touching 5-10 files) consistently take 45+ minutes.
- This breaks our 15-minute CI/CD gate requirement.

Key observations:
* The agent-based scan still seems to be analyzing large portions of the dependency tree, not just the changed files.
* The “pipeline scan” option had worse performance in our tests.
* Support cited “project complexity” and suggested we adjust scan settings, which degraded vulnerability detection.

Question for others: Is this typical? What scan configurations or pipeline setups have you used to get sub-15-minute feedback?

—D]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-veracode/">Veracode Reviews</category>                        <dc:creator>dianar</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-veracode/hot-take-their-marketing-claims-about-speed-dont-match-our-45-minute-scans/</guid>
                    </item>
				                    <item>
                        <title>Beginner asking: What exactly does a &#039;sandbox&#039; protect me from?</title>
                        <link>https://communities.stackinsight.net/community/cyber-veracode/beginner-asking-what-exactly-does-a-sandbox-protect-me-from/</link>
                        <pubDate>Tue, 21 Jul 2026 10:05:19 +0000</pubDate>
                        <description><![CDATA[Hi everyone, I&#039;ve been trying to wrap my head around application security tools and keep seeing &quot;sandbox&quot; mentioned as a key feature, especially with platforms like Veracode. I get the gener...]]></description>
                        <content:encoded><![CDATA[Hi everyone, I've been trying to wrap my head around application security tools and keep seeing "sandbox" mentioned as a key feature, especially with platforms like Veracode. I get the general idea—it's a safe, isolated environment—but I'm a bit lost on the specifics.

When I'm evaluating a new tool, I like to understand exactly what I'm paying for. So, what does a sandbox actually protect me from in practice? For example, does it mainly protect my live production data if I'm scanning a new build? Or does it protect the scanning process itself from causing issues in my development environment? I've used freemium project management tools where "sandbox" just meant a test workspace, but this seems more technical.

I'm trying to map this to real risks. If I'm onboarding my team to a new SAST service, I want to explain the benefits clearly. Is it about preventing accidental exposure of sensitive code during analysis? Or stopping a scan from somehow affecting my running applications? Any concrete examples would be so helpful.

Thanks for helping a newcomer navigate this! The security space has so many layers, and I just want to make sure I'm starting with the right foundation.

&#x270c;&#xfe0f; annie]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-veracode/">Veracode Reviews</category>                        <dc:creator>annie82</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-veracode/beginner-asking-what-exactly-does-a-sandbox-protect-me-from/</guid>
                    </item>
				                    <item>
                        <title>Did you see the Gartner placement? Does it match your experience?</title>
                        <link>https://communities.stackinsight.net/community/cyber-veracode/did-you-see-the-gartner-placement-does-it-match-your-experience-3/</link>
                        <pubDate>Tue, 21 Jul 2026 09:52:00 +0000</pubDate>
                        <description><![CDATA[Good morning everyone,

I spent some time this morning going through the latest Gartner Magic Quadrant for Application Security Testing, and Veracode’s positioning certainly gave me pause fo...]]></description>
                        <content:encoded><![CDATA[Good morning everyone,

I spent some time this morning going through the latest Gartner Magic Quadrant for Application Security Testing, and Veracode’s positioning certainly gave me pause for thought. As someone who has been involved in rolling out and managing Veracode across a few different microservices ecosystems, I'm always curious to see how these high-level analyses align with the day-to-day, hands-on reality of building and securing software.

The report highlights their strengths in comprehensive platform coverage (SAST, SCA, DAST) and their developer-centric approach, which I can largely endorse. The pipeline integration and the feedback loop to the IDE are, in practice, quite solid. Where I find my experience diverging a bit is perhaps in the "completeness of vision" dimension. Gartner often weighs strategic direction heavily, and while Veracode's cloud-native shift and focus on developer experience are clear, the practical implementation can sometimes feel... nuanced.

I'd like to open a discussion on a few specific points that I think any technical team evaluating or using the platform should consider:

*   **Pipeline Speed vs. Depth:** For a fast-moving microservice CI/CD pipeline, the "pipeline scan" (their lighter, faster SAST) is a lifesaver for developer feedback. However, we've occasionally found subtle, complex vulnerabilities that only the full "policy scan" (much slower) caught. This trade-off between speed and thoroughness is a real architectural decision.
*   **Remediation Guidance:** Their documentation and learning resources are extensive. Yet, for custom frameworks or less common languages, the guidance can become generic quickly. We've built internal playbooks to supplement this.
*   **The Platform Tax:** The value is in the integrated platform, no doubt. But for teams that are all-in on, say, GitHub Advanced Security for SCA and SAST, and perhaps a separate DAST tool, the argument for a single vendor becomes less compelling. The integration and data correlation are the key sells.

So, my question to the community is this: **does their current market placement match your operational experience?** I'm particularly interested in:

*   How the platform holds up in a large, polyglot microservices environment.
*   Your real-world experience with false positive rates and the tuning effort required.
*   Whether the pricing and packaging model feels aligned with the value delivered, especially as you scale.

Let's move beyond the quadrant graphic and talk about what it's like to actually work with the tooling every day.

—Felix]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-veracode/">Veracode Reviews</category>                        <dc:creator>Felix R.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-veracode/did-you-see-the-gartner-placement-does-it-match-your-experience-3/</guid>
                    </item>
				                    <item>
                        <title>Switched from Veracode to Snyk - 3 month update on false positives</title>
                        <link>https://communities.stackinsight.net/community/cyber-veracode/switched-from-veracode-to-snyk-3-month-update-on-false-positives/</link>
                        <pubDate>Tue, 21 Jul 2026 08:54:41 +0000</pubDate>
                        <description><![CDATA[After three months of migrating our SAST pipeline from Veracode to Snyk, the quantitative improvement in signal-to-noise ratio is substantial. Our engineering velocity on security remediatio...]]></description>
                        <content:encoded><![CDATA[After three months of migrating our SAST pipeline from Veracode to Snyk, the quantitative improvement in signal-to-noise ratio is substantial. Our engineering velocity on security remediation has increased, primarily due to a significant reduction in unactionable findings. This post details the operational impact, focusing on false positive rates and pipeline integration.

Our primary grievance with Veracode was the manual triage burden. While its depth is commendable, it often surfaced issues that were contextually irrelevant—for example, flagging hard-coded credentials in test fixtures or third-party library vulnerabilities that were patched in our layered Docker base images. Our weekly review sessions were becoming unsustainable.

The transition required re-architecting our CI gateways. Below is a simplified Jenkinsfile snippet showing our previous Veracode integration pattern and the new Snyk-based stage.

```groovy
// Previous Veracode Scan Stage (Jenkins)
stage('Veracode SAST') {
    steps {
        withCredentials() {
            sh '''
            # Wrapper script to upload artifact, initiate scan, and poll for results
            ./scripts/veracode_scan.sh --build-id ${BUILD_TAG}
            '''
        }
        // Failure was often informational; we frequently used `currentBuild.result = 'UNSTABLE'`
    }
}

// Current Snyk SAST &amp; SCA Stage (Jenkins)
stage('Snyk Security Scan') {
    steps {
        withDockerContainer(args: '-e SNYK_TOKEN', image: 'snyk/snyk:docker') {
            sh '''
            snyk code test --severity-threshold=high --sarif-file-output=snyk-code.sarif
            snyk container test our-app:${BUILD_TAG} --file=Dockerfile --severity-threshold=high --sarif-file-output=snyk-container.sarif
            '''
        }
        // Import results to Jenkins for visualization
        archiveArtifacts artifacts: '*.sarif', allowEmptyArchive: true
    }
    post {
        failure {
            // Fail the build only on high/critical severity issues we haven't acknowledged via .snyk policy
            echo "Security gate failed. Review Snyk reports."
        }
    }
}
```

**Key Observations:**
*   **False Positive Reduction:** Snyk's context-aware scanning—particularly its ability to respect `.snyk` policy files and its more accurate dependency graph—has cut our false positive rate by approximately 60-70% for SAST. Findings are more directly tied to actual runtime paths.
*   **Pipeline Efficiency:** The shift from a polling-based, asynchronous model (Veracode) to a synchronous, in-container scan (Snyk) reduced our security feedback loop from ~25 minutes to under 4 minutes per build.
*   **The Trade-off:** Snyk is less comprehensive on certain architectural flaw categories (e.g., specific cryptographic misuse patterns). We've mitigated this with a quarterly supplemental manual review, which is still less effort than the previous weekly triage.

Overall, the switch has been a net positive for our DevOps workflow. The reduction in noise has increased developer trust in security tooling, leading to more consistent engagement with genuine vulnerabilities. For teams heavily invested in containerized workflows and seeking faster, more integrated feedback, this approach warrants consideration.

--crusader]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-veracode/">Veracode Reviews</category>                        <dc:creator>ci_cd_crusader</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-veracode/switched-from-veracode-to-snyk-3-month-update-on-false-positives/</guid>
                    </item>
							        </channel>
        </rss>
		