Vulnerability Management Program (VMP)

1. Purpose

The Vulnerability Management Program describes how DevOpsSystems identifies, assesses, prioritizes, remediates, tracks, and communicates security vulnerabilities.

The purpose of this program is to support the security, stability, reliability, and continuous improvement of DevOpsSystems products and related development processes.

2. Scope

This program applies to:

• DevOpsSystems Marketplace apps,

• Forge apps,

• Data Center apps,

• source code repositories,

• build and release processes,

• development tools and systems used to maintain DevOpsSystems products,

• security reports submitted by customers, researchers, or internal team members.

Customer-managed Data Center environments are operated by customers. DevOpsSystems does not have direct access to such environments unless information is voluntarily provided through support or troubleshooting.

3. Relationship to Other Documents

This program complements the following documents:

• Security Policy – public overview of DevOpsSystems security principles and controls,

• Software Development Life Cycle (SDLC) – development, testing, release, and maintenance process,

• Service Level Agreement (SLA) – support channels and support response targets,

• Privacy Policies – data handling for apps and support channels.

If a security issue is also a customer support issue, both the SLA and this Vulnerability Management Program may apply. Remediation targets for vulnerabilities are defined in this document.

4. Governance and Responsibility

Overall coordination of vulnerability management is assigned to the security owner, technical lead, or another designated team member responsible for security-related topics.

Responsibilities include:

• reviewing incoming vulnerability reports,

• coordinating triage,

• assigning severity,

• planning remediation,

• tracking remediation progress,

• coordinating communication,

• reviewing lessons learned,

• improving processes and controls.

All team members involved in development, testing, release, or support are expected to follow this process.

4.1 Security Contact and Atlassian Marketplace Security (AMS)

DevOpsSystems maintains at least one designated security contact and an account on ecosystem.atlassian.net to receive notifications about product-related vulnerabilities through the Atlassian Marketplace Security (AMS) ticketing system.

The security contact is responsible for monitoring AMS tickets related to DevOpsSystems apps and for initiating the vulnerability management process described in this document.

5. Vulnerability Sources

Potential vulnerabilities may be identified through:

• automated dependency scanning,

• static application security testing,

• software composition analysis,

• secret detection,

• code review,

• pull request review,

• automated CI/CD checks,

• customer reports,

• security researcher reports,

• bug bounty programs where applicable,

• support requests,

• internal testing,

• third-party advisories,

• Atlassian Marketplace security requirements,

• Atlassian Marketplace Security (AMS) tickets,

• vendor security notices.

6. Tools and Systems

The vulnerability management process uses the following tools and systems.

7. Process Overview

The vulnerability management process follows these stages:

1. Identification

2. Acknowledgement

3. Triage and validation

4. Severity assessment

5. Remediation planning

6. Fix implementation

7. Verification

8. Release or mitigation

9. Communication

10. Closure

11. Lessons learned

8. Identification

A potential vulnerability may be identified internally or reported externally.

Reports should include as much information as possible, such as:

• affected product,

• affected version,

• deployment type,

• vulnerability description,

• reproduction steps,

• proof of concept where appropriate,

• potential impact,

• affected configuration,

• logs or screenshots if relevant,

• contact information for follow-up.

Security vulnerabilities should be reported through the Security Service Desk:

https://tickets.help.devopssystems.de/servicedesk/customer/portal/18/group/23/create/128

9. Acknowledgement

DevOpsSystems aims to acknowledge security reports according to the following targets.

Acknowledgement means that DevOpsSystems has received the report. It does not mean that the report has been confirmed as a vulnerability.

10. Triage and Validation

During triage, DevOpsSystems reviews whether the report is valid, reproducible, security-relevant, and applicable to supported products or versions.

Triage may include:

• confirming affected product and version,

• reproducing the issue,

• identifying affected deployment types,

• assessing exploitability,

• evaluating potential customer impact,

• checking whether a workaround exists,

• checking whether the issue is already known,

• assigning severity,

• creating or updating Jira tracking items.

11. Severity Classification

Severity is assigned based on technical impact, exploitability, affected data, affected systems, authentication requirements, customer impact, and available mitigations. DevOpsSystems uses the Common Vulnerability Scoring System (CVSS v3.x) base score as the primary reference for severity classification, consistent with the Atlassian Marketplace Security Bug Fix Policy.

Severity may be adjusted as more information becomes available.

12. Target Triage Timeframes

DevOpsSystems aims to complete initial triage according to the following targets.

These targets may vary depending on complexity, reproducibility, third-party dependencies, and availability of required information.

13. Remediation Planning

Once a vulnerability is validated and prioritized, remediation is planned and tracked.

Remediation may include:

• code changes,

• dependency updates,

• configuration changes,

• permission changes,

• documentation updates,

• operational mitigations,

• customer guidance,

• release of a fixed version,

• temporary workaround,

• risk acceptance where justified and approved.

14. Target Fix Timeframes

The following targets describe intended remediation timeframes after a vulnerability has been validated and prioritized. The Cloud / Forge targets are aligned with the Atlassian Marketplace Security Bug Fix Policy.

These are target timeframes, not guaranteed resolution times.

Actual remediation may depend on:

• complexity,

• product architecture,

• available mitigations,

• third-party dependencies,

• customer deployment models,

• Atlassian Marketplace processes,

• compatibility requirements,

• testing requirements,

• risk of regression,

• availability of required information.

15. Data Center Considerations

Data Center apps are installed in customer-managed environments. For Data Center products, remediation may require:

• creating a fixed app version,

• testing compatibility with supported host product versions,

• publishing the fixed version,

• customer installation or upgrade,

• customer-side configuration changes.

DevOpsSystems may provide mitigation guidance where a full fix requires customer deployment.

16. Verification

Fixes are verified before release where technically feasible.

Verification may include:

• automated tests,

• unit tests,

• integration tests,

• security tests,

• dependency scans,

• manual review,

• reproduction of the original issue,

• regression testing.

17. Communication

DevOpsSystems aims to communicate security-related updates responsibly and transparently while avoiding unnecessary exposure of exploit details.

Communication may include:

• support ticket updates,

• release notes,

• advisory notes,

• direct customer communication for relevant high-impact issues,

• Marketplace release information,

• documentation updates.

Critical and High vulnerabilities may require more direct communication if customers are likely to be affected and mitigation or upgrade action is required.

Details that could increase risk may be withheld until an appropriate fix or mitigation is available.

17.1 Public Vulnerability Overview

DevOpsSystems maintains a public vulnerability overview where disclosed security vulnerabilities for its apps are listed. The overview is publicly viewable by anyone:

https://devopssystems.atlassian.net/issues/?filter=10280

Users who want to be actively notified about new entries can subscribe to this filter. Subscribing requires signing in to the Atlassian instance beforehand. Please note that notifications are provided through the filter subscription itself; there is no separate email notification service.

18. Coordinated Disclosure

DevOpsSystems welcomes responsible disclosure.

Reporters are asked to:

• avoid accessing, modifying, or deleting data that does not belong to them,

• avoid disrupting customer systems,

• provide sufficient technical detail,

• keep vulnerability details confidential until coordinated disclosure is agreed,

• allow reasonable time for triage and remediation.

DevOpsSystems will review reports confidentially and coordinate communication where appropriate.

19. Risk Acceptance and Exceptions

In some cases, a reported issue may be accepted as low risk, not applicable, mitigated by platform controls, or not reproducible.

Risk acceptance or exceptions should be documented with:

• reason,

• scope,

• risk level,

• compensating controls,

• approver,

• review date.

20. Continuous Improvement

Vulnerability management is an ongoing process.

DevOpsSystems reviews findings, incidents, customer feedback, tooling results, and process outcomes to identify opportunities for improvement.

Improvements may include:

• stronger automated checks,

• additional tests,

• dependency update improvements,

• documentation improvements,

• development process changes,

• support process improvements,

• security training or awareness.

21. Related Documentation

• Security Policy

• Software Development Life Cycle (SDLC)

• Service Level Agreement (SLA)

• App Privacy Policy (Forge & Data Center)

• Help Portal Privacy Policy

• End-User License Agreement (EULA)

22. Review and Updates

This Vulnerability Management Program is reviewed periodically and may be updated to reflect changes in products, processes, tools, security requirements, or business operations.

Last updated: 2026-06-01