githubJul 22, 2026

Next chapter: Restructuring GitHub’s bug bounty program (opens in new tab)

GitHub is restructuring its bug bounty program to prioritize high-quality, high-impact security research over report volume. The changes introduce a permanent VIP program with higher rewards and faster support, reduce and simplify public-program payouts, and add submission limits for researchers without an established track record. Reports submitted before July 27, 2026 will remain under the previous terms. ## Permanent VIP program for top researchers GitHub is creating a private, invite-only program for researchers who consistently produce valuable findings. - VIP researchers receive: - Higher payouts - Faster response times - Closer collaboration with GitHub’s security engineering team - VIP bounty payouts are: - Low: $1,000 - Medium: $7,500 - High: $20,000 - Critical: $30,000+ - Researchers can qualify by achieving at least one of the following: - One critical finding - Two high-severity findings - Four medium-severity findings - Seven low-severity findings - The program emphasizes quality and impact rather than the number of submissions. ## Restructured public bounty payouts GitHub is replacing variable payout ranges with fixed amounts to make rewards more predictable and reduce administrative overhead. - New public-program payouts: - Low: $250 - Medium: $2,000 - High: $5,000 - Critical: $10,000 - GitHub may still provide discretionary bonuses for exceptional work. - The public program will remain an entry point for new researchers and a pathway into the VIP program. ## Higher submission standards To address increasing report volume, including low-effort and AI-generated submissions, GitHub is adding a HackerOne signal requirement. - Researchers below the required signal threshold will have a limited number of submissions. - New researchers can make up to four initial submissions while establishing credibility. - The goal is to reduce noise without excluding legitimate newcomers. ## Existing commitments and transition period GitHub says it will continue paying quickly, communicating clearly, and treating researchers as security partners. - Reports submitted before the changes take effect will follow the old bounty structure. - Reports submitted on or after July 27, 2026 will use the new rules. - GitHub also plans to improve response times, severity explanations, and community engagement through conferences and outreach. The restructuring is designed to make GitHub’s bug bounty program more sustainable while directing greater rewards and attention toward researchers who deliver deep, thoughtful security work.

vulnerability-managementapplication-securitybug-bountyhackerone+2

cloudflareJul 17, 2026

Cloudflare WAF protects WordPress applications from two high-severity vulnerabilities (opens in new tab)

Cloudflare has deployed WAF protections for two serious WordPress vulnerabilities: a high-severity SQL injection and a critical unauthenticated remote code execution flaw. The rules protect proxied WordPress sites on both free and paid Cloudflare plans, but they only reduce exposure while sites are patched. WordPress updates remain essential, with fixes available in versions 6.8.6, 6.9.5, 7.0.2, and 7.1 Beta 2. ## Vulnerabilities and Affected Versions - **CVE-2026-60137 — SQL injection** - Affects WordPress 6.8 and later. - Crafted input can alter database queries. - Rated High. - **CVE-2026-63030 — Unauthenticated RCE** - Affects WordPress 6.9 and later. - Exploits the REST API batch endpoint when persistent object caching is not enabled. - Requires no authentication or user interaction. - Rated Critical. - Versions earlier than 6.8 are not affected. - WordPress 6.8.6 fixes the SQL injection; later listed releases fix both vulnerabilities. ## Cloudflare WAF Protections - Cloudflare deployed the protections at **17:03 UTC on July 17, 2026**. - Both rules are enabled with a default **Block** action: - SQL injection rule: `1c060d3a371549219ee290d7ed933fcc` for Managed Rules and `db003b39b7774859a8d588ce33697a1a` for the Free Ruleset. - RCE rule: `7dfb2bd4708d4b88b9911dc0550664b6` for Managed Rules and `ebd3f2df15c74ddcbf6220c9b5ec246a` for the Free Ruleset. - The SQL injection rule blocks malicious parameter values before they reach WordPress. - The RCE rule targets requests attempting to access the vulnerable REST API path. ## Customer Actions - Pro, Business, and Enterprise customers should ensure Cloudflare Managed Rules are enabled. - Free-plan customers receive protection automatically through the Free Ruleset. - Review ruleset overrides, especially configurations that change blocking to logging. - Monitor Cloudflare Security Events for requests matching either rule. - Confirm that WordPress automatic updates succeeded and that the site runs a patched release. ## Ongoing Protection Cloudflare will monitor matching traffic and refine detections as attackers develop new variations. The WAF rules provide defense in depth, but they cannot repair vulnerable WordPress code. Administrators should patch WordPress immediately, verify that both WAF rules remain active with the **Block** action, and investigate suspicious requests if updating is temporarily impossible.

vulnerability-managementcloudflarerest-apiweb-application-firewall+3

gitlabJul 16, 2026

GitLab 19.2 release notes | GitLab Docs (opens in new tab)

GitLab 19.2, released July 16, 2026, focuses heavily on AI-assisted development, workflow automation, and centralized security controls. Major additions include the generally available GitLab Duo CLI and custom flows, scheduled pipeline execution policies, and Agentic Chat integrations. Several security features remain in beta, including automated dependency remediation and vulnerability tracking on non-default branches. ## AI-Assisted Development - **GitLab Duo CLI is generally available** for Premium and Ultimate users across GitLab.com, Self-Managed, and Dedicated. - Provides interactive chat and headless CI/CD modes. - Understands GitLab projects, pipelines, and agent configurations. - Supports model selection, shared sessions, tool approvals, MCP connections, slash commands, skills, and `AGENTS.md`. - Can be installed through `glab` or as a standalone tool. - **Custom flows are generally available** across all tiers. - Define reusable, YAML-based workflows for complex multi-step tasks. - Support multi-agent orchestration and human approval checkpoints. - Trigger from mentions, assignments, pipelines, and merge request events. - Offer project or AI Catalog management, visibility controls, secure service-account execution, and YAML validation. - **Foundational flows can now start from Agentic Chat.** - Developer Flow can implement changes or open merge requests. - Code Review Flow can review merge requests. - Fix CI/CD Pipeline Flow can diagnose and repair failed pipelines. - Users approve the handoff and monitor progress in chat or under AI sessions. ## Centralized Pipeline Automation - **Scheduled pipeline execution policies are generally available for Ultimate.** - Define schedules centrally in a security policy project. - Apply them across projects without modifying each project’s `.gitlab-ci.yml`. - Run compliance scripts, security scans, and other jobs independently of commit activity. - Support daily, weekly, or monthly schedules, time zones, time windows, and branch targeting. - Each policy creates a separate pipeline. ## Dependency and Vulnerability Management - **Dependency scanning auto-remediation is in beta.** - Automatically opens merge requests for vulnerable dependency upgrades. - Defaults to patch and minor version updates. - Agentic Breaking Change Resolution can address failed pipelines caused by complex or major upgrades. - GitLab Duo analyzes errors, changelogs, and code usage, commits fixes to the same merge request, and reruns the pipeline. - The feature creates an end-to-end remediation loop, from vulnerability detection through upgrade and repair. - **Non-default branch vulnerability tracking is in beta.** - Supports long-lived branches such as `project-qa`, `project-prod`, `project-iOS`, and `project-android`. - Allows branch-specific filtering in vulnerability reports and dashboards. - Tracks all vulnerability types, including CVEs. - Preserves vulnerability metadata when branches merge into the default branch. - Allows up to twice as many tracked branches as projects in the namespace. ## Governance and Administration - **Selective GitLab Duo availability is available for GitLab Dedicated and Dedicated for Government.** - Administrators can lock selected subgroups and descendants into an “Always off” state. - Other subgroups can retain the option to enable Duo according to their permissions. - The model provides a per-subgroup allowlist rather than disabling AI for the entire instance. - Owners receive clear messaging when a parent group has disabled the features. ## Contributor Recognition - GitLab recognized **vivekshukl007** as the month’s Notable Contributor. - Their contribution added Scala language support to GitLab Orbit, improving code graph capabilities for Scala projects. GitLab 19.2 is especially valuable for teams adopting AI-driven development and centralized security automation. Organizations should evaluate Duo CLI and custom flows for productivity gains, while testing the dependency remediation and non-default branch features carefully because they remain in beta.

vulnerability-managementgitlabmodel-context-protocolyaml+4

githubJul 9, 2026

How GitHub gave every repository a durable owner (opens in new tab)

Michael Recachinas is a Staff Security Engineer at GitHub who leads large-scale security initiatives. His work focuses on vulnerability management, secure development lifecycle tooling, and developer-first security automation. Throughout his career, he has built scalable systems designed to make secure choices easier for development teams. ## Professional Focus - Leads security programs at GitHub. - Specializes in: - Vulnerability management - Secure development lifecycle tooling - Security automation designed for developers ## Engineering Approach - Builds systems that operate at large scale. - Focuses on integrating security into developers’ workflows. - Aims to make secure practices the easiest and most natural choice. Overall, the passage presents Recachinas as a security engineering leader focused on scalable, practical, and developer-friendly solutions.

vulnerability-managementgithubsecurity-automationsecure-development-lifecycle+1

githubJul 2, 2026

How GitHub used secret scanning to reach inbox zero (opens in new tab)

Michael Recachinas is a Staff Security Engineer at GitHub who leads large-scale security initiatives. His work centers on vulnerability management, secure development lifecycle tooling, and automation that helps developers make secure choices more easily. ### Professional Focus - Leads security programs at scale. - Focuses on: - Vulnerability management - Secure development lifecycle tools - Developer-first security automation ### Experience and Approach - Has built systems designed to operate reliably at large scale. - Emphasizes making secure behavior the easiest option for development teams. The provided text is a professional biography rather than a full technical blog post, so it does not include a specific argument, technical sections, or conclusion to summarize.

vulnerability-managementgithubapplication-securitysecurity-automation+1

githubJun 29, 2026

Inside the Advisory Database and what happens when vulnerability volume breaks records (opens in new tab)

Madison Ficorilli is a vulnerability transparency advocate and senior security manager at GitHub. She leads the advisory database curation team and contributes to vulnerability reporting, response, and disclosure through several industry organizations. Her perspective combines current leadership experience with prior roles in incident response and vulnerability coordination. ## Leadership at GitHub - Leads GitHub’s advisory database curation team. - Focuses on improving vulnerability transparency and the quality of security advisory information. ## Industry and Open Source Security Work - Co-chairs a relevant Open Source Security Foundation (OpenSSF) working group. - Serves on the CVE Program Board. - Advocates for effective vulnerability reporting, response, and disclosure practices. ## Professional Background - Previously worked as a product incident response analyst at GitHub. - Served as a vulnerability coordinator at the CERT Coordination Center at Carnegie Mellon University’s Software Engineering Institute. Her career reflects deep expertise across vulnerability coordination, incident response, database curation, and security disclosure policy.

vulnerability-managementgithubincident-responsecve+2

gitlabJun 18, 2026

One vulnerability view: From scanner coverage to AI governance (opens in new tab)

GitLab 19.1 presents a unified approach to application security and AI governance. It lets organizations enforce third-party SARIF-compatible scanners across every project, centralize findings, and automate remediation. At the same time, new AI governance features record agent activity and require approval for sensitive actions, enabling faster development without sacrificing accountability. ## Enforcing Complete Scanner Coverage - Security scanners are often configured separately for each project, creating coverage gaps and policy drift. - GitLab 19.1 allows administrators to enforce third-party scanners across all projects. - SARIF-compatible scanner results flow into GitLab’s unified vulnerability view. - Findings use the same governance and remediation workflows as GitLab-native results. - GitLab Duo Agent Platform can: - Triage findings with SAST False Positive Detection. - Generate merge requests through Agentic SAST Vulnerability Resolution. - Automatically remediate third-party scanner findings before production. ## Improving Secret Detection - Secret detection now scans every commit on a newly created branch, rather than only the latest commit. - This helps identify credentials introduced in earlier commits. - Secret False Positive Detection, now generally available, provides: - A confidence score for each finding. - An explanation displayed in the vulnerability report. - Developers can focus on genuine exposures instead of test credentials, placeholders, and example tokens. ## Governing AI Agent Actions - AI coding agents can create merge requests, invoke tools, commit code, and modify projects. - GitLab’s AI audit event streaming beta records every agent action and sends it to existing audit log destinations. - Agent tool approval guardrails let administrators configure each tool to: - Run automatically. - Require human approval. - Remain blocked. - Sensitive operations, such as writing files or deleting resources, can therefore require explicit review. - Approval decisions are also recorded, creating an auditable history for incident response and compliance. ## Governed Autonomy GitLab’s overall goal is to combine autonomous development with enforceable controls. Organizations can prove scanner coverage, automate vulnerability remediation, restrict risky agent behavior, and review a complete audit trail of what agents did. The practical recommendation is to centralize scanner governance and configure approval requirements for high-impact AI actions, allowing agents to work quickly while keeping security and accountability under human control.

vulnerability-managementgitlabdevsecopssast+4

cloudflareJun 9, 2026

Defend against frontier cyber models: Cloudflare's architecture as customer zero (opens in new tab)

Frontier cyber models primarily change the speed and scale of attacks, not the fundamental stages of intrusion. They can rapidly discover vulnerabilities, generate exploit variations, and adapt around defenses, making architectural resilience more important than patch speed alone. Cloudflare’s approach is to use layered controls, limit the reach of compromised identities, and turn broad network visibility into faster defensive action. ## What Frontier Cyber Models Change - Models such as Mythos can accelerate: - Vulnerability discovery across large codebases and open-source dependencies - Exploit-chain reasoning - Proof-of-concept generation - Reconnaissance and attack variation - Traditional intrusion stages—reconnaissance, initial access, lateral movement, persistence, and exfiltration—remain, but attackers can execute them faster and at greater scale. - Attackers need only one exploitable opening, while defenders must identify and secure all of them. - AI-generated fixes can introduce regressions, meaning faster patch creation does not eliminate testing and review constraints. ## Three Threats Driving the Architecture ### Faster Vulnerability Discovery - Frontier models can search widely used open-source libraries and frameworks at scale. - A library flaw is only exploitable when attacker-controlled input can reach the vulnerable code and surrounding protections are insufficient. - The most concerning risk is the gap between attacker discovery and defender awareness. - Organizations should assume attackers are already using these models against their code if they are not doing so themselves. ### Higher Exploit Volume and Adaptation - Models can generate thousands of exploit variants and conduct reconnaissance at comparable scale. - Signature-based defenses may still block many variants sharing the same underlying pattern. - The greater danger is adaptive behavior: a model can probe a WAF, learn which payloads are blocked, and rewrite attacks until they evade the rule. ### Limiting Impact After Exploitation - No security architecture prevents every compromise. - The critical question is how far an attacker can move using a single identity, route, or credential. - If one compromise provides unrestricted access, the surrounding architecture—not just the original vulnerability—is the fundamental weakness. ## Visibility as a Defensive Advantage - Cloudflare observes roughly one-fifth of global web traffic, providing real-time insight into: - Mutating attack payloads - Emerging patterns - New attacker tooling and campaigns - Cloudforce One converts this network visibility into threat intelligence, tracked adversaries, campaigns, and indicators of compromise. - The key challenge is reducing the delay between discovering a threat and applying an effective mitigation across defensive systems. ## Practical Recommendation Organizations should run frontier models against their own code, strengthen layered detection, and design systems so that a single compromised identity or credential cannot provide unrestricted access. Architecture, containment, and rapid use of threat intelligence are essential complements to patching.

vulnerability-managementcloudflareai-securityweb-application-firewall+2

gitlabMay 26, 2026

Reduce supply chain risk with SBOM-based dependency scanning (opens in new tab)

SBOM-based dependency scanning in GitLab 19.0 addresses the limits of traditional scanners that focus only on declared packages and known CVEs. It inventories direct and transitive dependencies, traces how vulnerable packages entered a project, and identifies whether application code actually reaches them. The result is more targeted remediation and easier organization-wide enforcement of supply chain security. ## Why Traditional Dependency Scanning Falls Short - Modern applications rely heavily on third-party and deeply nested dependencies. - Supply chain compromises can affect every project that depends on a vulnerable package. - AI-generated code further increases risk, with research indicating that nearly half contains vulnerabilities. - Teams need to know not only which packages are vulnerable, but also: - How they entered the project - What dependencies they brought with them - Whether the application actually uses them ## How SBOM-Based Scanning Works - The analyzer inventories dependencies in a CycloneDX-format software bill of materials. - Components are matched against the GitLab Advisory Database to identify known vulnerabilities. - Findings appear in: - Merge requests, so developers can address issues before release - Vulnerability dashboards and reports, for centralized security oversight - GitLab produces both an SBOM and a dependency scanning report for compliance and supply chain tooling. ## Tracing and Prioritizing Vulnerabilities - The analyzer follows transitive dependency chains regardless of nesting depth. - Teams can see the path a vulnerable package took into the project—for example, `library-a` → `library-b` → `library-c`. - For Java, JavaScript/TypeScript, and Python, GitLab checks whether vulnerable packages are directly imported or required. - Findings include reachability status, helping teams prioritize vulnerabilities their code can plausibly execute. - Scans can run on merge requests, pipeline executions, and when new advisories are published, including for production systems with little ongoing development. ## Supported Ecosystems and Input Files - The release supports more than 24 package ecosystems, with additional support planned. - Lockfiles and dependency graphs are preferred because they provide complete transitive dependency information. - If those are unavailable, the analyzer can parse manifests such as: - `pom.xml` - `requirements.txt` - Gradle build files - Manifest scanning identifies direct dependencies but offers less complete coverage because transitive dependencies may be missing. ## Centralized Configuration and Enforcement - GitLab 19.0 provides a security configuration profile for applying dependency scanning across many projects. - Security and platform teams can configure scanning once instead of maintaining individual pipeline files. - Scan execution policies and pipeline execution policies can enforce requirements at the group or instance level without modifying `.gitlab-ci.yml` files. - Centralized policies reduce configuration drift, skipped projects, and audit gaps. ## Availability and Migration - SBOM-based dependency scanning is available to GitLab Ultimate customers on GitLab.com and is rolling out to Dedicated and self-managed installations. - Teams migrating from Gemnasium can run both analyzers in parallel and compare their results. - GitLab provides setup instructions, migration guidance, and documentation for supported languages and advanced configuration. Teams should prefer lockfile-based SBOM scanning, enable it centrally through security policies, and prioritize remediation based on dependency reachability rather than vulnerability presence alone.

vulnerability-managementgitlabdevsecopsdependency-scanning+4

gitlabMay 13, 2026

5 ways to fix misleading vulnerability severities with policy (opens in new tab)

CVSS scores describe a vulnerability’s general characteristics, not its actual risk in a specific environment. GitLab severity override policies let teams automatically adjust findings based on CVE, CWE, file path, or directory, reducing manual triage. The result is a vulnerability report that better reflects deployment context, exploitability, and organizational priorities. ## How Severity Override Policies Work - Policies run automatically on every default-branch pipeline. - Rules match findings by: - CVE identifier - CWE identifier - File path - Directory - Available actions: - **Set Severity** to informational, low, medium, high, or critical - **Increase Severity** by one level - **Decrease Severity** by one level - Manual overrides by authorized users take precedence. - GitLab records automated changes in vulnerability history and audit events. ## Downgrading Low-Risk CVEs in Internal Services - Internal tools and services may have substantially lower exposure than public-facing applications. - A policy can reduce the severity of selected CVEs found under paths such as `internal/**/*`. - The `decrease` operation lowers severity by one level—for example, Critical to High or High to Medium. - Teams should replace the example CVEs with vulnerabilities they have assessed as less risky in internal deployments. ## Upgrading Injection Vulnerabilities in Production Code - XSS (`CWE-79`) and SQL injection (`CWE-89`) are frequently exploited vulnerability classes. - Findings involving these CWEs under `src/**/*` can be forced to **Critical**. - Combining this override with a merge request approval policy can require security-team review before affected code reaches production. ## Normalizing Severity Across Scanners - SAST, dependency, and container scanners may assign different severities to the same CVE. - A policy can set specific vulnerabilities—such as Log4Shell-related CVEs—to a consistent baseline, such as High. - This produces more predictable triage and approval thresholds across scanning tools. ## Incorporating Exploitation Intelligence - CVSS is largely static and does not reflect changes in real-world exploitation. - EPSS and CISA’s Known Exploited Vulnerabilities catalog provide signals about exploitation likelihood and active attacks. - Teams can explicitly upgrade CVEs identified as actively exploited or highly likely to be exploited, treating them as Critical regardless of their original scanner rating. GitLab severity overrides are most useful when they encode a documented risk model: deployment exposure, vulnerability type, scanner consistency, and current threat intelligence. They should complement—not replace—manual review, auditability, and merge request approval controls.

vulnerability-managementgitlabyamlsast+4

gitlabApr 22, 2026

GitLab Patch Release: 18.11.1, 18.10.4, 18.9.6 | GitLab Docs (opens in new tab)

GitLab released patch versions 18.11.1, 18.10.4, and 18.9.6 on April 22, 2026, addressing multiple security vulnerabilities and bugs in CE and EE. Self-managed installations should upgrade immediately, while GitLab.com is already patched and GitLab Dedicated customers need no action. The fixes include unauthenticated GraphQL and browser-based attacks, several denial-of-service flaws, and access-control weaknesses. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - Affects all deployment types unless otherwise specified, including Omnibus, source installations, and Helm charts. - Recommended fixed versions: - 18.11.1 - 18.10.4 - 18.9.6 - GitLab issues detailing security vulnerabilities are made public 30 days after the relevant patch release. - GitLab publishes both scheduled patch releases, issued on the second and fourth Wednesdays, and ad-hoc critical patches for high-severity vulnerabilities. ## High-Severity Vulnerabilities - **CVE-2026-4922 — GraphQL CSRF** - CVSS 8.1. - An unauthenticated attacker could execute GraphQL mutations on behalf of an authenticated user because of insufficient CSRF protection. - Affects versions before 18.9.6, 18.10.4, and 18.11.1. - **CVE-2026-5816 — Web IDE path validation** - CVSS 8.0. - Under certain conditions, improper path validation could allow unauthenticated attackers to execute arbitrary JavaScript in a user’s browser session. - Affects the 18.10 and 18.11 release lines before the listed patches. - **CVE-2026-5262 — Storybook cross-site scripting** - CVSS 8.0. - Improper input validation could allow unauthenticated access to tokens in the Storybook development environment. - Affects versions from 16.1 through the unpatched 18.9, 18.10, and 18.11 releases. ## Denial-of-Service Fixes - **CVE-2025-0186:** Crafted requests to the discussions endpoint could exhaust server resources. - **CVE-2026-1660:** Improper input validation during Jira issue imports could enable resource exhaustion. - **CVE-2025-6016:** Insufficient limits when retrieving notes could cause service disruption. - **CVE-2025-3922:** Resource-allocation weaknesses in the GraphQL API could allow authenticated users to overwhelm the system. - Each issue carries a CVSS score of 6.5 and generally requires authentication. ## Access-Control and Session Fixes - **CVE-2026-6515 — Virtual registry credentials** - CVSS 5.4. - Invalidated or incorrectly scoped credentials could continue accessing Virtual Registries. - **CVE-2026-5377 — Confidential issue titles** - CVSS 4.3. - Authenticated users could potentially view titles of confidential or private issues in public projects. - **CVE-2026-3254 — Mermaid sandbox** - CVSS 3.5. - Improper validation could allow authenticated users to load unauthorized content into another user’s browser. - The release also lists **CVE-2025-9957**, involving improper access control in the project fork relationship API; the provided text does not include its full impact or severity details. Self-managed GitLab administrators should apply the appropriate patch release as soon as possible, especially because several vulnerabilities permit unauthenticated browser or API attacks.

vulnerability-managementgitlabgraphqlcross-site-scripting+4

gitlabApr 20, 2026

Prepare your pipeline for AI-discovered zero-days (opens in new tab)

AI is accelerating both vulnerability discovery and insecure code production, shrinking the time defenders have to respond from months to hours. The post argues that security teams cannot remain the final defense layer; security controls, automated triage, and remediation must operate directly within development pipelines. AI-generated fixes can help close the gap, but they must follow the same policies, approvals, testing, and audit requirements as human-authored code. ## The Remediation Backlog Is Already Too Large - Most exploited vulnerabilities are already known and have patches available, but organizations cannot remediate them quickly enough. - Sixty percent of breaches in the 2025 Verizon DBIR involved known vulnerabilities. - Developers spend roughly 11 hours per month fixing vulnerabilities after release. - The median time to close half of internet-facing vulnerabilities is 361 days, while exploitation can begin within hours. - AI-assisted development is increasing the volume of insecure code: - Fortune 50 repositories reportedly gained more than 10,000 security findings per month by mid-2025. - AI coding tools may introduce outdated patterns, hallucinated packages, insecure examples, and excessive dependencies. - Security AI should therefore operate within existing development policies and audit trails rather than as a disconnected tool. ## Security Enforcement Must Move Into the Pipeline - Every change should pass security controls at the merge request, which becomes the central enforcement point. - Policies should be defined once and applied consistently across teams and projects. - Exceptions should be explicitly approved and logged. - IDE checks can catch straightforward problems—such as hardcoded secrets, vulnerable imports, and deprecated APIs—before code reaches review. - This allows human reviewers to focus on complex issues such as reachability, exploitability, and architectural risk. ## Automated Triage and Governed Remediation - AI should reduce the volume of findings developers must investigate by assessing: - False positives - Reachability - Exploitability - Severity - AI-generated fixes should not bypass normal governance. - Remediation proposals should be submitted as merge requests, with: - Required scans - Policy enforcement - Human approvals - Confidence scores - Complete audit records - Human and AI-authored changes should follow the same review and compliance process. ## Example: Responding to an Emerging Vulnerability - A proof-of-concept exploit may appear before a CVE, NVD entry, or scanner signature exists. - A security agent can inspect dependency graphs across projects, identify affected versions and call paths, and rank production exposure. - Teams can then launch a coordinated remediation campaign: - Upgrade dependencies where patches exist. - Apply targeted code changes where they do not. - Block merge requests that retain the vulnerable dependency. - Require security approval for fixes. - Pipeline tests can reject faulty AI-generated patches, allowing the agent to revise them before developers approve the corrected version. - Automatically collected scan results, policies, approvals, and merge timestamps provide audit evidence without manual reconstruction. ## Strengthen the Pipeline Before Attackers Catch Up - Organizations should verify that security scans run on every merge request, not only in selected projects. - Pipelines should detect compromised or vulnerable dependencies before build time. - Critical findings should move quickly from detection to the responsible developer without unnecessary tool boundaries. - The central recommendation is to make pipeline enforcement, AI-assisted triage, and governed remediation standard parts of the software supply chain before comparable offensive AI capabilities become widely available.

vulnerability-managementdatabase-designdevsecopsai-ml+4

githubMar 26, 2026

A year of open source vulnerability trends: CVEs, advisories, and malware (opens in new tab)

The passage identifies a security professional involved in several major vulnerability-management initiatives. They curate the GitHub Advisory Database, participate in GitHub’s Security Lab, issue CVE IDs, and publish CVE records. ### Responsibilities and Affiliations - Works as a security analyst. - Curates entries in the GitHub Advisory Database. - Is a member of the Security Lab. - Helps issue CVE identifiers for vulnerabilities. - Publishes official CVE records. Overall, the individual contributes to documenting, coordinating, and communicating software security vulnerabilities.

vulnerability-managementcvesecurity-analystgithub-advisory-database+1

gitlabMar 25, 2026

Manage vulnerability noise at scale with auto-dismiss policies (opens in new tab)

GitLab’s auto-dismiss vulnerability policies reduce scanner noise by automatically dismissing findings that teams have already determined are irrelevant, non-actionable, or mitigated. Policies match vulnerabilities by file path, directory, or identifier such as a CVE or CWE, while preserving dismissed findings and their audit history. This lets security teams focus on genuine risks without repeatedly performing the same manual triage. ## Why Auto-Dismiss Policies Matter - Security scanners often flag: - Test code and fixtures - Vendored or third-party dependencies - Generated files - Known false positives - Vulnerabilities addressed by existing controls - Manual dismissal creates: - Slower triage - Alert fatigue - Developer friction - Repeated work across projects and pipelines - Auto-dismiss policies allow teams to: - Apply triage decisions consistently at scale - Record a specific dismissal reason - Link findings back to the policy that dismissed them - Keep dismissed vulnerabilities visible for future review ## How Policies Work - Policies are defined in a vulnerability management policy YAML file. - Rules can match: - File paths - Directories - Vulnerability identifiers, including CVEs and CWEs - Teams create the policy through **Secure > Policies > New policy > Vulnerability management policy**. - After the merge request is merged, matching findings on default-branch pipelines are automatically marked **Dismissed**. - GitLab processes up to 1,000 vulnerabilities per pipeline run. - Teams can filter reports by **Dismissed** to evaluate policy impact and verify that the correct findings were handled. ## Dismissing Test Code Findings Test directories commonly contain intentionally insecure credentials, fixtures, or development-only dependencies that do not represent production risk. - Policies can target paths such as: - `test/**/*` - `tests/**/*` - `spec/**/*` - `__tests__/*` - The recommended dismissal reason is `used_in_tests`. ## Dismissing Vendored Dependencies Code in `vendor/`, `third_party/`, `vendored/`, or checked-in `node_modules` is often maintained upstream rather than by the application team. - Directory-based rules can identify these locations. - The example policy uses the `not_applicable` dismissal reason. - Teams should customize the directory patterns to match their repository structure. ## Dismissing Known False-Positive CVEs Repeatedly flagged CVEs that have been confirmed not to apply to an organization’s environment can be dismissed centrally. - Rules match specific identifiers, such as: - `CVE-2023-44487` - `CVE-2024-29041` - `CVE-2023-26136` - The sample policy uses `false_positive`. - The listed CVEs are examples and should be replaced with identifiers validated by the organization. ## Dismissing Generated Code Generated files from Protobuf, gRPC, OpenAPI, ORM, and similar tools may contain patterns scanners flag even though developers do not author or directly patch them. - Example matches include: - `generated/*` - `**/*.pb.go` - `**/*.generated.*` - The suggested dismissal reason is `not_applicable`. ## Dismissing Infrastructure-Mitigated Vulnerabilities Some vulnerabilities may be addressed by enforced runtime controls, such as WAF rules. - The example targets: - `CWE-79` for cross-site scripting - `CWE-89` for SQL injection - It uses the `mitigating_control` dismissal reason. - This approach should only be used when the mitigation is verified, consistently deployed, and reliably protects all affected paths. ## Practical Recommendation Use auto-dismiss policies for well-understood, documented cases—not as a substitute for vulnerability investigation. Start with narrowly scoped path or identifier rules, review the dismissed results regularly, and ensure every dismissal reason reflects a decision that remains valid.

vulnerability-managementgitlabdevsecopsyaml+3

gitlabMar 19, 2026

GitLab 18.10 brings AI-native triage and remediation (opens in new tab)

GitLab 18.10 adds AI-powered security features designed to reduce vulnerability triage noise and speed remediation. GitLab Duo Agent Platform can assess whether SAST and secret-detection findings are likely false positives, explain its reasoning, and— for verified SAST issues—generate tested fixes in merge requests. These capabilities are available to GitLab Ultimate customers using the Duo Agent Platform, with some features still in beta. ## SAST False Positive Detection - Generally available for new critical and high-severity SAST findings. - Uses LLM-based agentic reasoning to assess whether a vulnerability is likely real or a false positive. - Adds: - A confidence score - An AI-generated explanation - A “Likely false positive” or “Likely real” badge - Findings can be filtered in the Vulnerability Report so teams can prioritize likely real vulnerabilities. - The assessment remains a recommendation that teams can review and audit. ## Agentic SAST Vulnerability Resolution - Currently in beta. - For findings judged unlikely to be false positives, the agent: - Reads the vulnerable code and its surrounding context - Generates a proposed fix - Validates the fix with automated tests - Opens a merge request for developer review - The merge request includes code changes, a confidence score, and an explanation of the remediation. - Developers should still carefully review AI-generated changes before merging. ## Secret False Positive Detection - Currently in beta. - Identifies likely test credentials, placeholder values, example tokens, and other dummy secrets. - Provides confidence scores, explanations, and visual badges in the Vulnerability Report. - Runs automatically on the default branch and can also be triggered manually with “Check for false positive.” - The goal is to help teams focus on exposed credentials that represent genuine risk. GitLab 18.10 extends AI assistance across the vulnerability lifecycle: filtering out misleading findings, explaining security assessments, and proposing validated code fixes. Teams using GitLab Ultimate and Duo Agent Platform can use these features to reduce review effort while retaining human control over security decisions and merges.

vulnerability-managementgitlabsastmerge-requests+4