CloudBees takes security very seriously and investigates all reported vulnerabilities. We want to keep our software and services safe for everybody. We welcome working with the security community to resolve valid issues promptly.
Bounty Program
CloudBees offers monetary bounties for reports of qualifying security vulnerabilities. Reward amounts will vary based on the severity of the report, and eligibility is at our sole discretion. Not all submitted items will be in scope for a reward. Duplicate issues will be merged.
Our determination of what is in scope or not is final. Awarded bounties are not negotiable, including the decision to not pay out a bounty.
Program Scope
CloudBees oversees a large scope of products. Some projects fall under the scope of the open source Jenkins project, and as such will be handled by that security team following their documented processes at https://jenkins.io/security/. Any submissions to the CloudBees HackerOne program that fall under the scope of the Jenkins project will be forwarded to that team for further analysis, and follow-up will be handled via that team. Such reported vulnerabilities MAY be subject to bounties at the discretion of the CloudBees security team.
Within the CloudBees portfolio, the following products are in scope:
- CloudBees Console (app.cloudbees.com, id.cloudbees.com, and associated services)
- CloudBees CI and associated plugins (aka CloudBees Core)
- CloudBees CD (aka Flow)
- CloudBees CodeShip (SaaS service - codeship.com)
- CloudBees Websites (www.cloudbees.com, support.cloudbees.com)
- CloudBees Platform (cloudbees.io and sub-domains)
For a more detailed list, see “Scopes” (visible only to invited testers). Vulnerabilities reported against unlisted domains MAY be subject to bounties at the sole discretion of the CloudBees security team.
Please note that just because you find the same issue within multiple domains in our portfolio, it does not mean we will treat them as separate issues. Please don't open multiple tickets for the same issue for each domain, as we will just mark them as duplicates
Testing accounts and traffic categorisation
When performing testing on our SaaS applications, please ensure the testing accounts registered on our applications follow either format below. Not following this guidance might be a reason for disqualifying your finding.
- Use a +h1 suffix on the username, for example “+h1@”; OR
- Use the @wearehackerone.com e-mail address assigned to your HackerOne account
- Researchers must add headers to requests such as: “X-HackerOne-Research: [H1 username]”
Other good practices on this can be found (although not mandatory) here
Third-party applications behind CloudBees domains
At CloudBees we rely on many third-party SaaS applications to help us deliver final services or products. Many of those might be behind domains we control such as the list below, although not limited to it:
Our stance on such applications is that they are partially in-scope. Issues related to how CloudBees has configured and integrated with these services will be considered in scope. Testers reporting flaws that lie fully within the third party service will be redirected to the security programs of the respective service. The CloudBees security team makes the final determination of whether a report is in scope.
Consider the case of exposed storage buckets, for example. We welcome reports of misconfiguration issues, but if there is a flaw in the core storage service, the best target for such a report would be the cloud provider since they are in the best position to fix it.
We will assess the reports the same way we do it with other reports, although if we don’t find any data compromise on such applications it is unlikely we will take it as a report for our program.
Areas of highest interest
We are most interested in, and will pay higher bounties for:
- OWASP top 10 related issues, such as demonstrated XSS
- Anything that allows bypass of the authentication system (aside from brute forcing or DoS style attacks)
- Things that would expose private user data in ways that are not intended.
- Ability to modify or inject content into any of our public web properties
- Cloud Security configuration issues related to cloud infrastructure used by our SaaS services (AWS, Google Cloud, Kubernetes), leading to exploitable vulnerabilities.
Areas of lowest interest
We are not particularly interested in:
- Blatant dumps of information from scanning tools. Do not dump your burp suite findings with links to public pages about why that finding is bad. You must demonstrate an actual exploitable issue.
- CVEs for versions of software you may identify we are running unless you can point to an actual vulnerability
- Reports of best practices you feel CloudBees should be following
- Reports involving low or medium issues surrounding our authentication/login system (including things like best practices, rate limiting, etc).
- Reports of sub-domain takeovers or dangling domains (will likely be pay low at most)
Common Reports we get that are out of scope
- Any and all reports regarding password complexity
- DKIM/SPF/DMARC/etc settings for email of domains we own
- Clickjacking on pages with no sensitive actions.
- Unauthenticated/logout/login CSRF.
- Attacks requiring MITM or physical access to a user's device.
- Previously known vulnerable libraries without a working Proof of Concept.
- Comma Separated Values (CSV) injection without demonstrating a vulnerability.
- Missing best practices in SSL/TLS configuration.
- Any activity that could lead to the disruption of our service (DoS).
- Content sniffing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
- Open redirects unless there's an actual security issue associated with it. Manually changing the URL in a redirect is not sufficient cause for a security issue. Tampering with an existing redirect that legitimately tricks an actual user to a different site IS valid.
- Information disclosure-looking vulnerabilities for keys and tokens that are supposed to be client/browser bound.
- Weak 2FA implementation and/or session configuration related vulnerabilities that do not result in a full account take-over will have their severity rated Low or even None. For example: session invalidation on password changed
- uds.cloudbees.com / app.cloudbees.com (also beescloud.com) self-organisation IDOR vulnerabilities
While researching we ask that you do not perform the following:
- Any type of Denial of Service
- Spamming/Messaging
- Social Engineering attempts on CloudBees employees or contractors
- Any physical attempts to access to CloudBees offices
Disclosure Policy
- As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organisation.
- Follow HackerOne's disclosure guidelines.
What we expect from you
- Strictly follow this policy and the H1's (code of conduct](https://www.hackerone.com/policies/code-of-conduct)
What to expect from us
- Our goal is to triage your report as per the program response targets. We will work with our engineering teams to take scope of severity, business impact, and how we fit any potential fixes into our work queue. Please note that most reported items are not business critical, and as such it takes some time for our teams to determine exactly the scope of the issue, and how it will be addressed. Once we have a good idea of how it will be fixed and the overall severity, we will pay a bounty. Our preference is to pay a bounty at the same time we validate resolution of the issue as it allows us to make sure the amount of the bounty is appropriately tied to the actual problem.
- In some cases the item filed may be (by our team) considered more of a bug than a security issue. We may still elect to fix and pay out bounties for such items, but there is no particular timeline for addressing them as our product management teams will be scoping them into the product plan details.
- While we appreciate your reports, asking the status of when we will respond, fix the item, or post a bounty will not receive a response. Repeated attempts at asking for status of such reports may result in banning from continued participation in our program.
This program page may be updated at any time.
