AWS launches first public Vulnerability Disclosure Program (with no bounty)

AWS has partnered with HackerOne to launch its first public Vulnerability Disclosure programme – although details about “bounties” remain thin. 

Amazon itself operates a generous public bug bounty scheme that pays up to $25,000 to security researchers who identify vulnerabilities.

But AWS had not previously disclosed even the existence of a private programme for third-party security researchers to submit vulnerabilities.  

AWS’s Ryan Nolette announced the “VDP”at fwd:cloudsec Europe in a presentation called: "Doing bad things for the right reasons: A look at the AWS vulnerability disclosure and remediation process." (See a full live stream here and slides from the security engineer’s presentation at here.)

Nolette's announcement also appeared to confirm long-standing rumours that AWS has a private bug bounty program, with one slide revealing that people who submitted bugs are eligible to join an "invite-only project".

He later confirmed this program and told The Stack: "There are no monetary rewards in a VDP. However, members in the program can earn nominations to the private invite-only AWS Bug Bounty Program."

On the webpage for the VDP, the AWS Security Outreach Team excitedly told researchers: "We are excited to collaborate with you!"

"Amazon Web Services is committed to collaborating with the security community to identify and address vulnerabilities, ensuring the safety of our businesses and customers," the AWS team wrote. "We deeply value your contributions and take all security reports with utmost seriousness."

Nick Frichette, Staff Security Researcher, told The Stack that the AWS move was helpful, but fell short of the public bug bounty program the security community "has been asking for".

"I’m excited that AWS is moving in the right direction when it comes to publicly recognising researchers and providing a more streamlined experience when disclosing vulnerabilities," he said. "The next step would be for it to launch a full public bug bounty.”

In a thread on X (which you can see below), Frichette said a rumoured private bug bounty program was "the worst-kept secret in AWS security." A public scheme is preferable to one that takes place behind closed doors, he said, because researchers are less likely to be able to share their findings publicly.

"There have been a number of hints that AWS has had some sort of bug bounty program, such as job postings for people to manage it," Scott Piper, Principal Cloud Security Researcher at Wiz, also told us.

"The recent VDP on HackerOne is a little confusing as to whether it is a bug bounty or just a separate flow for their existing vulnerability disclosure process, which historically is done by emailing aws-security@amazon.com.

"You'll find all complaints about AWS's vuln disclosure process mention that it 'does not have a public bug bounty program', from which one can make some assumptions about why the word 'public' is always mentioned there."

How I disclose a bug to AWS and is there a bounty?

Anyone who submits a vuln to AWS will be protected by Gold Standard Safe Harbor, which safeguards good faith security research - an activity AWS regards as "authorised activity that is protected from adversarial legal action by us".

Investigators will need to follow HackerOne's disclosure guidelines. AWS will then "work to validate the reported vulnerability" or "work with you to obtain" further information.

"When the initial investigation is complete, results will be delivered to you along with a plan for resolution and discussion of public disclosure," AWS wrote.

If the vulnerability is found to affect a third-party product in the AWS cloud, the hyerscaler will notify the owner of the technology - without disclosing the name of the researcher.

Amazon's CNA (CVE Numbering Authority) will issue CVEs that "support customers in addressing valid security vulnerabilities" as long as they fall within these classes:

• AWS Services delivered by AWS and publicly available to customers. Examples: EC2, Amazon RDS.
• Amazon Services delivered by Amazon and publicly available to customers. Examples: Amazon[.]com Seller API Service.
• Open-source software within a GitHub organization managed by Amazon or AWS.
• Client software published by Amazon or AWS and available for download from a website or download location owned and operated by us. Examples: Amazon Appstore s:SDK, Amazon Input SDK, Amazon Kindle App, Amazon MShop App, Amazon WorkSpaces client.
• Devices manufactured by Amazon or AWS and available to customers for purchase and use. Examples: Amazon Fire TV, Amazon Echo devices, Amazon Kindle, AWS Outpost.

Additionally, the bug must be "customer-impacting" and exist in an "Amazon or AWS-owned class which is publicly available to customers."

It must also have a CVSS score of 4.0 (a medium rating) and involve "customer agency".

Read this: AI is helping hyperscalers “burn” customer money: In the real world, CIOs, spies fret

AWS wrote: "Remediation of supported or EOL/EOS product issues requires customer action, including making a risk-based decision on handling the remediation (OR customers need to assess possible impact) OR when a valid security vulnerability will become public (OR has the potential of becoming public)."

The hyperscaler advised anyone reporting potential vulnerabilities to "focus on realistic attack scenarios and the security impact of the behaviour". Some activities are out of scope for the AWS Vulnerability Reporting Program, so getting involved in such wickedness may "result in disqualification from the program permanently."

For example, theoretical vulnerabilities requiring unlikely user interactions, like those affecting unsupported browsers, broken link hijacking, or tabnabbing, are ineligible.

Similarly, vulnerabilities without real-world security impact, such as clickjacking on non-sensitive pages or CSRF on logout forms, do not qualify.

AWS also excludes optional security hardening steps, such as SSL/TLS configurations and lack of SSL pinning, as these are considered best practices rather than critical flaws. Hazardous testing methods, like attempts to generate excessive traffic or social engineering, are also prohibited unless pre-authorized, ensuring AWS system availability and security are not compromised.

We have written to AWS for comment.

Join peers following The Stack on LinkedIn