Automating CNA CVE Reporting and Monthly Bulletins at Atlassian

Automating CNA CVE Reporting and Monthly Bulletins at Atlassian

Speakers: Deepak Chintala (Engineering Manager, Atlassian); Zachary Echouafni (Security Engineer, Atlassian)

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=e7EnCS2kUxc

Overview

In an era where software supply chain security and transparent vulnerability disclosure are paramount, Atlassian, a major enterprise software provider, has transformed its Common Vulnerabilities and Exposures (CVE) reporting program from a labor-intensive manual process into a highly efficient, automated pipeline. Presented by Deepak Chintala, Engineering Manager, and Zachary Echouafni, Security Engineer, this VulnCon talk, "Automating CNA CVE Reporting and Monthly Bulletins at Atlassian," details their multi-year journey to build an event-driven service atop Atlassian's cloud stack. The initiative was born out of necessity, driven by the scale of Atlassian's product portfolio and the stringent compliance requirements of its Fortune 500 customer base.

The talk illuminates the challenges faced by large organizations acting as a CVE Numbering Authority (CNA), particularly when managing vulnerabilities across diverse product offerings and deployment models (cloud and on-premise data centers). The speakers share candid insights into the "battle scars" and "success stories" encountered while evolving from a human-centric, crisis-mode disclosure system to a sustainable, scheduled, and fully automated program. This transformation not only streamlined internal operations but also significantly bolstered customer trust and improved the security posture of Atlassian’s vast user ecosystem.

This article delves into the technical architecture, operational shifts, and profound impacts of Atlassian's automated CVE program. It highlights how strategic investment in coordinated disclosure, backed by intelligent automation, can dramatically reduce operational overhead, enhance transparency, and accelerate the adoption of critical security patches by customers. For any organization grappling with the complexities of vulnerability management and disclosure at scale, Atlassian's blueprint offers invaluable lessons and a compelling vision for the future.

Background

▶ Watch: Introduction and manual CVE challenges (0:00)

Atlassian’s diverse product suite, including ubiquitous tools like Jira, Confluence, Bitbucket, Loom, and Trello, serves a global customer base that prominently features Fortune 500 companies. This extensive reach, coupled with the critical role Atlassian products play in enterprise operations, elevates CNA status from a "good to have" to a fundamental requirement. As a CNA, Atlassian becomes the authoritative source for vulnerabilities within its products, necessitating rigorous processes for coordinated disclosure.

Historically, Atlassian’s CVE program was a manual, arduous undertaking. In its early days, the process involved security engineers manually crafting complex JSON blocks and submitting pull requests to the Mitre CVE list GitHub repository. This workflow, while functional, was "slow, error-prone, and exactly not the kind of work a security engineer would rather find exciting to do," as highlighted by Deepak Chintala. Each disclosure was effectively a "mini project," consuming valuable engineer time on peer reviews of JSON files rather than higher-value security tasks. The situation was further complicated by the existence of dashboards tracking "age of unreported vulnerabilities," indicating a significant backlog of patched issues awaiting disclosure. Engineers relied on cumbersome CLI tools, contributing to an environment of "ad-hoc chaos."

This manual pipeline was primarily designed for "crisis mode" — urgent disclosures for critical vulnerabilities. It proved unsustainable for the steady stream of vulnerabilities identified through various sources, including bug bounties, penetration tests, and Software Composition Analysis (SCA) findings. The manual reporting journey involved five bottlenecked steps, starting from vulnerability identification and patching, through public Jira ticket creation, security review, JSON file generation, GitHub PR submission, and finally, CVE issuance. Any revision to version numbers or contested CVSS vectors would send the process back to step two, creating a "security engineer's telephone game that no one really wanted to play." Atlassian's use of a public Jira instance (jira.atlassian.net) for tracking all issues, including security vulnerabilities, further amplified the pain, as customers could directly comment on security bugs, often leading to "spicy" and resource-intensive interactions.

The manual approach also created a significant burden on customer support. At one point, 13% of all support inquiries were CVE-related, with customers submitting "huge Excel sheets with hundreds and hundreds [of] rows of CVE IDs" generated by tools like Black Duck or other SCA scanners, demanding manual triage. This "massive resource drain" eroded customer trust and even slowed down sales cycles. Despite significant effort from the data center teams to fix vulnerabilities, only 11% of first-party issues were being disclosed. This meant Atlassian had "all the fixes, but we were lacking a microphone to talk about it to our customers," a critical disconnect that undermined their security investments. The necessity for a more efficient and transparent system for data center customers, who require formal CVEs for their stringent compliance and maintenance schedules, ultimately spurred the decision to overhaul the entire CNA program.

Key Findings

▶ Watch: Automating CNA program: Key capabilities (14:00)

Atlassian's journey to automate its CNA CVE reporting yielded several transformative findings, demonstrating the profound impact of strategic automation on vulnerability management at scale. The core discovery was that a fully automated, event-driven pipeline could not only eliminate significant manual toil but also fundamentally shift the organization's approach to security disclosure from reactive to proactive and predictable.

Firstly, the project successfully established automated CVE record reservation, monthly security bulletins, and a streamlined critical advisory process. By integrating internal Atlassian products like Jira and Confluence with the Mitre CVE Services API, the team created a system capable of handling a continuous stream of vulnerability disclosures. This allowed Atlassian to scale its disclosure efforts dramatically, moving beyond a "crisis mode" mentality to a regular, scheduled cadence for all applicable vulnerabilities.

A major finding was the significant reduction in operational overhead and customer support burden. The automation led to a 90% reduction in CVE-related customer support questions, effectively eliminating the need for dedicated personnel to triage these inquiries. This efficiency translated into 60 work weeks saved in engineering time, equivalent to gaining one full-time employee dedicated to operational tasks. This highlights the substantial return on investment in automation for security teams.

Furthermore, the program achieved a monumental improvement in disclosure coverage, increasing from a mere 11% to 100% of both first-party vulnerabilities and third-party Software Composition Analysis (SCA) findings. This comprehensive coverage ensured that customers had a complete and accurate picture of their security posture regarding Atlassian products. Crucially, the predictable and high-quality disclosures directly impacted customer behavior, reducing the average customer upgrade timeframe for security fixes from 91 days to 28 days. This accelerated adoption of patches signifies a tangible improvement in the overall security posture of Atlassian's customer base, demonstrating that transparency and reliability build trust and drive positive security outcomes.

Finally, the initiative underscored the importance of high-quality, machine-readable CVEs and range-based versioning. Initial confusion arising from linear version reporting (e.g., "vulnerable from version 7 onwards") necessitated a shift to explicit, range-based affected versions (e.g., "8.5.0 to 8.5.3 is vulnerable"). This precision, coupled with the auto-templating of vulnerability descriptions using CWEs and CVSS vectors, ensured that scanning tools could accurately identify vulnerabilities, thereby empowering customers to better manage their environments and significantly reducing the need for manual interpretation and support queries.

Technical Deep Dive

▶ Watch: Demo: Automated CVE reservation and drafting (19:00)

Atlassian's automated CVE reporting system is a sophisticated, event-driven architecture built primarily on the Atlassian Cloud platform, leveraging its native automation capabilities and custom application development. The core objective was to transform a manual, error-prone workflow into a highly efficient, scalable, and transparent disclosure engine.

The foundation of the automation lies in Atlassian's cloud development tools:

• Automation rules: These are no-code, workflow-driven rules within Jira that react to specific events (e.g., status changes on a ticket). They can execute actions like making API calls, formatting data, or applying regex for pattern matching. While powerful for simpler tasks, early limitations included the lack of secure secret storage, which was a significant hurdle for integrating with external APIs requiring authentication. This feature has since been added, making automation rules more versatile.
• Connect apps: These are applications built to extend Atlassian products, typically involving a microservice hosted outside the Atlassian Cloud that listens for events (e.g., ticket creation or updates) and performs custom logic. Atlassian initially utilized a Connect app for its CVE integration.
• Forge: This is Atlassian's modern, serverless platform for building cloud apps. Forge apps are Node.js applications that run directly within the Atlassian Cloud on a Lambda-like environment. This eliminates the need for external microservices, offering performance benefits (due to co-location with Jira instances) and simplified deployment. Atlassian is currently migrating its Connect apps to Forge, recognizing it as the future for robust, cloud-native integrations.

The CVE ticket integration is central to the system. A custom app (initially Connect, migrating to Forge) serves as the bridge between internal Jira tickets and the external Mitre CVE Services API. This app enables security engineers to reserve and publish CVE numbers directly from a Jira ticket. Initially, due to perceived instability and responsiveness issues with the Mitre API, Atlassian implemented a CVE pool mechanism, reserving blocks of CVEs (e.g., 10 per month) based on anticipated consumption. This proactive reservation minimized direct API calls during critical disclosure windows. The speakers noted that the Mitre API has since matured, making the pooling less critical, but it highlights a practical solution to external service reliability challenges. The integration also auto-syncs data from Atlassian's public Jira issue tracker to the internal CVE record, pulling essential information such as the CVE description and affected/fixed versions, which are crucial for generating Common Platform Enumeration (CPE) records to ensure discoverability by vulnerability scanners.

A critical component is the sanitization process. When a vulnerability is patched internally, an event triggers an app to create a sanitized draft version of the public Jira issue. This ensures that sensitive details, such as exploit methodologies from bug bounty reports, are not publicly disclosed. Concurrently, the app auto-drafts the CVE record in the Mitre CVE Services API and the internal record view, preparing it for human review and eventual release.

The system scopes vulnerabilities from a comprehensive set of sources:

• Human-generated sources: Bug bounty programs, internal and third-party penetration tests, and internal security reviews.
• Automated sources: Software Composition Analysis (SCA) tools that scan S-bombs for known vulnerabilities in third-party components.
• External reports: Customer or researcher reports, and vulnerabilities identified from public news or advisories.

To ensure high-quality and actionable public disclosures, the system employs auto-templating for public issue content:

• CWEs (Common Weakness Enumerations): These are leveraged from commercial scanners for SCA findings. If a CWE is not available, the system uses keyword matching (e.g., regex for "remote code execution" or "cross-site scripting") to infer and classify the vulnerability.
• CVSS (Common Vulnerability Scoring System) vector: Atlassian requires a CVSS vector for all triaged vulnerabilities. The system extracts metadata from this vector (e.g., "Attack Vector: Remote") to inform the description, providing context on exploitability (e.g., whether the vulnerability requires network access or is locally exploitable).
• Vulnerability patch advice: The system automatically includes recommended upgrade versions. This is particularly complex for Atlassian due to non-linear versioning and long-term release cycles (e.g., multiple major versions, each with individual back-ported fixes). To address this, the system queries an internal release database (powered by Atlassian Bamboo, their continuous delivery server). This database provides precise fixed version ranges (e.g., "8.5.0 to 8.5.3 is vulnerable, upgrade to 8.5.4"), preventing issues where a blanket "vulnerable from version 7 onwards" would incorrectly flag future, patched versions. This granular versioning is vital for accurate CPE generation and scanner compatibility.

The entire system culminates in a monthly security bulletin cockpit, a dedicated Jira ticket that aggregates all applicable vulnerabilities released in the past 40 days that are in a draft state. This cockpit orchestrates the human review process, assigning tasks to specific product teams and security personnel. It also features a "Confluence page" that is auto-generated with a table of CVEs, including affected ranges and a single recommended fix version for all CVEs released that month for a given product. This streamlined view simplifies the patching process for customers. The system is event-based, meaning any changes to the Jira ticket (e.g., removing a CVE) automatically regenerate the public Confluence page, ensuring real-time accuracy. This collaborative, time-zone-agnostic review process, spanning a week, involves 12 collaborating teams (9 product teams) and is crucial for maintaining the quality and accuracy of disclosures before they are publicly released and synchronized with NVD and Atlassian's public CVE portal.

Demo / Proof of Concept

▶ Watch: Impact: Reduced support, saved time, faster upgrades (41:00)

The talk included compelling demonstrations of the automated processes, illustrating how Atlassian transitioned from manual toil to a streamlined, event-driven disclosure pipeline.

The first demonstration showcased the CVE Record Automation (starting around 19:30). Zach navigated an internal Jira ticket, which was linked to a corresponding public issue. The internal CVE record view automatically populated with crucial data such as the CVE description, affected versions, and fixed versions, essential for generating accurate CPE records. The key interaction was a simple workflow transition button labeled "Reserve CVE." Upon clicking this, the system, via its integration with the Mitre CVE Services API, fetched a new CVE number (e.g., CVE-202X-XXXXX) and assigned it to the Jira ticket within approximately 10 seconds. This demonstrated the rapid, on-demand generation and assignment of CVEs, a task that previously involved manual API calls or GitHub submissions. Once reserved, the CVE was then scheduled for release, linking back to the public Jira issue on the National Vulnerability Database (NVD). A practical tip shared was to utilize the Mitre CVE Services API's development instance for testing, preventing accidental publication of junk data during development.

The second, more elaborate demonstration focused on the Monthly Security Bulletin Cockpit (starting around 31:30). This "cockpit" is a dedicated Jira ticket designed to manage the entire monthly disclosure cycle. It aggregates all applicable vulnerabilities from the past 40 days that are in a draft state. The demo highlighted several key features:

• Triaging and Review Links: The cockpit provided direct links to internal drafts and a preview of the public bulletin, allowing reviewers to see exactly what customers would eventually read.
• Assigned Tasks: It showed tasks assigned to specific individuals or teams (e.g., "Zach reviewed his product"), indicating the status of their review stage. This distributed responsibility across engineering teams, ensuring relevant stakeholders reviewed their respective product's vulnerabilities.
• Inclusion/Exclusion of Issues: A critical feature was the ability to manually add or remove vulnerabilities from the bulletin at the last minute. This flexibility accounts for automation bugs, misfiled issues, or urgent late additions from researchers.
• Engineering Team View: The demo illustrated what an engineering team member would see: a limited scope of CVEs relevant to their product (e.g., two CVEs for "Bamboo"). Their primary task was to confirm the accuracy of versioning data (affected and fixed versions) and review the public draft.
• Auto-Templated Confluence Page: The public view of the bulletin was an auto-generated Confluence page, featuring a table of CVEs hyperlinked to their respective public Jira tickets. This table consolidated information for customers, often recommending a single upgrade version to fix all CVEs released that month for a given product. The dynamic nature of the system was evident when a CVE was removed from the cockpit; the public Confluence page automatically regenerated, updating the version range and removing the deleted entry.
• Workflow Progression: The demo concluded with the reviewer marking their task as "done" and approving the bulletin, signifying the completion of their review step in the coordinated, time-zone-agnostic process.

These demonstrations collectively illustrated the power of Atlassian's automated system in simplifying complex, multi-stage processes, ensuring data accuracy, and facilitating collaborative reviews across a global enterprise.

Defensive Implications

▶ Watch: Q&A: Critical vulnerabilities and upgrade timelines (48:00)

Atlassian's automated CNA program has significant defensive implications, both for its vast customer base and for other organizations seeking to mature their vulnerability management and disclosure practices.

For Atlassian Customers:

• Predictable Patching Schedules: Data center customers, who often operate in highly regulated and air-gapped environments, can now anticipate and plan for monthly security upgrades. The reduction in average upgrade time from 91 to 28 days is a direct result of this predictability. Customers can integrate Atlassian's monthly bulletin release day (the third Tuesday of the month) into their regular maintenance schedules, ensuring timely application of patches.
• Enhanced Self-Service and Transparency: Atlassian's public Jira instance and the dedicated CVE portal provide self-service access to comprehensive, high-quality CVE information. Customers can leverage the API of the CVE portal to set up automated daily checks for new Atlassian CVEs, integrating this data into their internal vulnerability management systems (e.g., Black Duck, OSV). This transparency reduces reliance on manual support inquiries and empowers customers to proactively assess their exposure.
• Clearer Vulnerability Assessment: The shift to precise, range-based versioning (e.g., "8.5.0 to 8.5.3 is vulnerable") dramatically improves the accuracy of customer vulnerability scanners and S-bomb analysis. This clarity helps customers quickly determine if they are genuinely affected by a CVE, avoiding the confusion previously caused by broad, linear versioning statements.
• Critical Advisory Responsiveness: While the monthly bulletin handles routine high-severity issues, the separate critical advisory process ensures that customers are immediately notified of and provided patches for critical vulnerabilities (CVSS 9-10) or those under active exploitation. This multi-tiered approach provides robust protection for the most severe threats.

For Other CNAs and Organizations:

• Necessity of Automation for Scale: Any organization operating as a CNA or managing a large product portfolio must invest in automation. Manual processes are unsustainable, leading to backlogs, errors, and significant resource drain. Atlassian's 60 work weeks saved and 90% reduction in support inquiries demonstrate the compelling ROI of such an investment.
• Leverage Existing Internal Tools: Atlassian's success in building its system on its own Jira and Confluence cloud stack highlights the potential of repurposing and extending existing enterprise tools for security operations. This reduces the need for entirely new infrastructure and leverages familiar workflows.
• Prioritize High-Quality, Machine-Readable Disclosures: The shift from ambiguous to precise versioning, coupled with auto-templating using CWEs and CVSS vectors, is crucial. High-quality CVEs are essential for interoperability with customer scanning tools and for minimizing post-disclosure support queries.
• Establish Cross-Functional Review Processes: Even with extensive automation, human review remains vital for coordinated and responsible disclosure. Designing a collaborative, time-zone-agnostic review process involving both security and product engineering teams ensures accuracy, aligns with release cycles, and distributes responsibility effectively.
• Transparency Builds Trust: Regular, predictable, and transparent disclosures, coupled with self-service documentation, are powerful tools for building customer trust. This transparency showcases security investments and can even accelerate customer adoption of patches, improving the collective security posture of the ecosystem.
• Align Release Cycles: For organizations with multiple product lines, aligning vulnerability patch release cycles (e.g., to a 28-day cadence) is a significant challenge but a critical enabler for a predictable disclosure program. This ensures patches are available concurrently with CVE disclosure.

In essence, Atlassian's experience provides a robust blueprint for how organizations can move beyond basic vulnerability management to truly effective, transparent, and customer-centric coordinated disclosure, turning a compliance burden into a strategic security advantage.

Key Takeaways

• Automation is Paramount for Scale: Manual CVE reporting is unsustainable for large product portfolios and complex customer demands. Atlassian's shift to an event-driven, automated pipeline drastically reduced manual toil and enabled comprehensive disclosure.
• Significant ROI and Operational Efficiency: The automated program saved 60 work weeks of engineering time (equivalent to one FTE) and achieved a 90% reduction in CVE-related customer support inquiries, demonstrating a clear return on investment.
• Achieving 100% Disclosure Coverage: Atlassian increased its vulnerability disclosure coverage from 11% to 100%, encompassing both first-party issues and third-party SCA findings, providing customers with a complete security picture.
• Accelerated Customer Patching: Predictable, high-quality disclosures directly led to a reduction in average customer upgrade times for security fixes from 91 days to 28 days, significantly improving their overall security posture.
• Strategic Use of Internal and External Tools: Leveraging Atlassian's own cloud stack (Jira, Confluence, Forge/Connect apps) and integrating with the Mitre CVE Services API formed the technical backbone of the successful automation.
• Importance of High-Quality, Granular Data: Precise, range-based versioning in CVEs and auto-templating descriptions with CWEs and CVSS vectors are crucial for machine-readability, scanner compatibility, and reducing customer confusion.
• Collaborative, Cross-Functional Review is Key: Even with high automation, a structured, time-zone-agnostic human review process involving both security and product engineering teams is essential for maintaining disclosure quality and accuracy.

About the Speaker(s)

Deepak Chintala is an Engineering Manager within the Product Security team at Atlassian. With over six years of experience at the company, Deepak initially joined as a Principal Engineer and has recently transitioned into a management role. His expertise lies in product security, guiding teams in securing Atlassian's extensive ecosystem.

Zachary Echouafni is a Security Engineer and a Technical Lead for the Product Security team at Atlassian. He is deeply involved in securing Atlassian's marketplace, which hosts thousands of third-party applications, and leads vulnerability management initiatives. Prior to his current focus, Zach played a pivotal role in building out Atlassian's internal vulnerability management space and developing the automated CNA program that was the subject of this talk.