Giter Site home page Giter Site logo

disclose / diodb Goto Github PK

View Code? Open in Web Editor NEW
955.0 77.0 302.0 6.3 MB

Open-source vulnerability disclosure and bug bounty program database

Home Page: https://disclose.io/programs/

License: Creative Commons Zero v1.0 Universal

Python 85.63% Shell 14.37%
security-research safe-harbor-framework responsible-disclosure vulnerability-disclosure disclosure-policy simplicity legal safety bug-bounty hackers

diodb's People

Contributors

0ddinput avatar abhinavprasad47 avatar adiffpirate avatar arn3tt avatar bad5ect0r avatar barnett avatar bcdavidchou avatar beauwoods avatar cablej avatar caseyjohnellis avatar codingo avatar dantrauner avatar dasqrd avatar davidhalfpenny avatar edoverflow avatar faykus avatar gamliel972 avatar gbroiles avatar hakluke avatar jeffboothby avatar klepas avatar knightpfhor avatar martin005 avatar nikitastupin avatar prodigysml avatar rajanimesh64 avatar rootup avatar sickcodes avatar whiteroses avatar yesnet0 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

diodb's Issues

Create automated test cases for CSV:JSON drift

Post #102 a build script (likely in tavis) should be deployed to this repository to block pull requests where the programs-list.csv does not match programs-list.json contents to ensure both files are accurate and up to date.

Github Actions to check for duplicate entries

#196 introduced a double up of each entry that wasn't caught in review. In order to prevent repeat cases of this, or minor double ups, a Github actions entry should be created that checks for any double ups of the program name at the time when a new pull request is created, and if so, fail the case.

Possible mismatch in terms

The core terms include the following item:

  • Keep the details of any discovered vulnerabilities confidential until they are fixed, according to the Disclosure Terms in this policy;

My reading of this is that it is referring to whether this is coordinated, discretionary or non-disclosure as defined in variable.md. However in the variable.md these items are under a heading of Disclosure Policy, not Disclosure Terms.

Is my reading of this correct? Should this be standardised on term/policy?

Adopt industry standard term: coordinated disclosure

The term responsible disclosure has a long history of being used to strong arm security researchers by vendors. The security industry has largely settled on the use of coordinated disclosure and I recommend that this repo follow suit.

SSL verification fails validation links action

Validation links action errors when visiting a URL. The following error message provides proof:

1751. vkksu.gov.ua (https://www.vkksu.gov.ua/userfiles/doc/sec/secpolicy.txt): HEAD: write EPROTO 140411183376256:error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol:../deps/openssl/openssl/ssl/statem/statem_lib.c:1929:
. Trying GET...
GET: write EPROTO 140411183376256:error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol:../deps/openssl/openssl/ssl/statem/statem_lib.c:1929:

Proposal to track disclosure type in addition to safe harbor type

A company's willingness to disclose reported vulnerabilities can be of interest to researchers when evaluating programs, in addition to safe harbor. As described in the disclose.io terms, disclosure types can include coordinated disclosure, discretionary disclosure, and non-disclosure:

  • Coordinated Disclosure: A researcher can share details of the vulnerability after a fix has been applied and the program owner has provided permission to disclose, OR after 90 days from submission, whichever is sooner,
  • Discretionary Disclosure: The researcher or the program owner can request mutual permission to share details of the vulnerability after approval is explicitly received, or
  • Non-Disclosure: Researchers are required to keep vulnerability details and the existence of the program itself confidential.

To that end, I suggest adding a public_disclosure field to each program. As with the safe_harbor field, the public_disclosure field can have one of three values: "coordinated" for coordinated disclosure, "discretionary" for discretionary disclosure, and "" or "none" for non-disclosure.

Such a change will both aid researchers and enable tracking disclosure trends across VDPs over time.

Public Disclosure Field Discussion: disclosure_timeline_days type requirement is overly strict for some policies

I'm noticing that none of the policies currently listed have disclosure_timeline_days set. However, it's a requirement if co-ordinated is set. This seems like overly restrictive for a org declaring their disclosure policy. Our policy states:

Provide us with a reasonable amount of time to remedy the vulnerability before sharing the details of the vulnerability with the public, and in any event, avoid sharing any details of the vulnerability publicly until you have at least received an acknowledgement from us regarding the reported vulnerability;
- https://github.com/gradle/.github/blob/master/SECURITY.md

Our policy is attempting to allow public disclosure, but not set any hard deadlines on anyone's disclosure timeline. Not sure how to communicate this with the current schema requirements:

"if": {
"properties": {
"public_disclosure": {
"const": "co-ordinated"
}
}
},
"then": {
"required": ["disclosure_timeline_days"]
},

Make landing page/docs more actionable

I don't have specific suggestions, but as a <user?> coming to this page/project, I think it could be more clear what I can do to get started. Thoughts?

[idea] Automatically sync programs from `chaos.projectdiscovery.io`

Hi ๐Ÿ‘‹

projectdiscovery/public-bugbounty-programs project is similar to diodb in a sense that it collects public bug bounty programs. projectdiscovery/public-bugbounty-programs is actively maintained and contains programs that disclose/diodb don't. We can write a script that will periodically sync programs from projectdiscovery/public-bugbounty-programs to disclose/diodb.

Here are few concerns:

  • chaos and diodb differs in JSON schema they use thus automatic sync may not be possible (needs research)
  • chaos may break at some point and script may breaking part of diodb because of it

Both concerns are mitigated in case of partially automatic sync (e.g. script does PR and human approves PR).

s/bug_bounty/vulnerability_disclosure_program/g

Many of the programs listed in bug_bounty_list.json are not actually bug bounties (they don't offer payment). They'd be more accurately described as vulnerability disclosure (programs|services) or something like that. Bug bounties are a kind of vdp, but not the only kind represented in your list.

Update https://github.com/disclose/diodb/blob/master/program-list/program-list-schema.json to reflect new data schema

field required type options source/s description
program_name no string name pr The commonly used name for the program.
policy_url yes string url security.txt, pr The URL referring to the official public policy.
contact_url yes string url, mailto security.txt, pr The official communication channel for the program as defined by the policy.
launch_date no date date pr The date of program launch.
offers_bounty no enum yes, no, partial pr Does the policy state that the program offers a cash or cash-equivalent reward?
offers_swag no boolean yes, no pr Does the policy state that the program offers a non-cash reward or token of thanks?
hall_of_fame no string url security.txt, pr The URL of the hall of fame for the program. NULL if none are present.
safe_harbor no enum full, partial, none pr The safe harbor status of the program according to the definitions at https://disclose.io
public_disclosure yes enum nda, discretionary, co-ordinated, NULL pr The public disclosure policy as stated in the program policy. NULL if none are present.
disclosure_timeline_days no(yes if public_disclosure = co-ordinated) int(unsigned) number pr If the program uses a proactive policy, the agreed number of days between submission of a vulnerability and publicly disclosure of the vulnerability.
pgp_key no string url security.txt, pr The URL to the PGP in-use for encrypting submissions. NULL if none are present.
hiring no string url security.txt, pr ย 
securitytxt_url no string url security.txt, pr ย 
preferred_languages no string text security.txt ย 

Consider adding platform name to the list schema

For many researchers, it would be interesting to know if a particular program is running on a platform such as HackerOne, BugCrowd, etc. We are proposing that the list schema be augmented with a new field to indicate the platform.

[US Election] Leased/Rented voting equipment scope question

Out-of-scope systems include infrastructure or other equipment not owned by participating state agencies and their county and local subdivisions. It is the responsibility of vulnerability researchers, testers, or others seeking to comply with this policy to ensure the equipment or system is not out-of-scope.

What about systems that are leased/rented? Can these systems not be considered in-scope?

Financing options. In addition to an outright purchase, vendors may offer lease options to jurisdictions looking to acquire a new system.
- https://www.ncsl.org/research/elections-and-campaigns/voting-equipment.aspx

What would program runners need to do to include leased equipment in scope?

Making it easier for non-Github users to update diodb

As someone who has an addition or change to make to diodb but is not conversant with git or Github (e.g. legal team, marketing team, executive, etc) I would like to be able to use a web-based form to submit a change.

As a maintainer, I'd like submissions from the form above to be checked against the existing database to determine whether they are a new entry or an update. Given the user isn't a git native, I also presume they might have trouble with json and don't assume they've been able to do this check themselves.

Conceptually: Web form -> json -> Duplicate check action -> PR creation action -> PR created

You link Wrong responsible disclosure program

Hi Team,

I submit these to bugcrowd they replied

"If you'd like to make your contributions there and mention this submissions id"

My submission id :- https://bugcrowd.com/submissions/006b732c015aedaad89952024774058a0f7d395c30ec92fa3db0d5f10754b15e

So these are the program which wrong link

  1. ABNAMRO BANK It will redirect to Royal Bank of Scotland [https://personal.rbs.co.uk/personal/fraud-and-security/responsible-disclosure.html] which is not of ABNAMRO BANK

    1. The ABNAMRO BANK responsible disclosure [https://www.abnamro.com/en/footer/responsible-disclosure.html]
  2. Lumosity program link to Lookout program [https://www.lookout.com/legal/responsible-disclosure]

  3. Tin foil program link to TION group also TION group point to Tin foil

  4. Edmodo point to Bugcrowd [https://www.bugcrowd.com/bug-bounty-list/]

  5. Bime is point out to other but it's real program on hackerone [https://hackerone.com/bime]

Thanks

Clearer, enforced schema for program-list.json

Issue #205 prompts me to suggest a few more changes.

The schema (and data) should be changed to make it easier to interpret the safe_harbor values, by replacing "" with "none".

The .github/pull_request_template.md should be changed to ask if the data follows the schema.

It would also be nice to check for consistency in an automated integration test.

Create test case for enforcing valid links

As we add more links and this is subject to change over time a test case should be deployed to ensure that all links within the repository are valid at each instance when a new pull request is created

Sort entries in bug-bounty-list.json

While it probably doesn't matter much from a programmatic sense, having the entries sorted would be nice from a human sense.

Using something like jq, this would be as easy as (note: piping could probably be better.. doing it directly seemed to clobber the end file, but i'm sure that's easilysolvable):

cat bug-bounty-list.json | jq 'sort_by(.program_name)' --raw-output > bug-bounty-list2.json
mv bug-bounty-list2.json bug-bounty-list.json

Inconsistency in JSON

The bentley program safe_harbor field is unquoted, and such is treated as a boolean instead of a string.

    {
        "program_name": "Bentley",
        "policy_url": "https://www.bentley.com/responsible_disclosure.pdf",
        "submission_url": "https://www.bentley.com/en/about-us/contact-us/contact-us-form?topic=11",
        "launch_date": "",
        "bug_bounty": true,
        "swag": true,
        "hall_of_fame": true,
        "safe_harbor": true
    },

compared to another program

    {
        "program_name": "Better",
        "policy_url": "https://bugcrowd.com/better",
        "submission_url": "https://bugcrowd.com/better/report",
        "launch_date": "",
        "bug_bounty": true,
        "swag": false,
        "hall_of_fame": true,
        "safe_harbor": "full"
    },

Additionally, there are capitalised and lowercase variants for some of the data.

$ curl https://raw.githubusercontent.com/disclose/disclose/master/program-list/program-list.json 2> 
/dev/null | grep "safe_harbor" | sort -u
        "safe_harbor": ""
        "safe_harbor": "false"
        "safe_harbor": "full"
        "safe_harbor": "none"
        "safe_harbor": "None"
        "safe_harbor": "partial"
        "safe_harbor": "Partial"
        "safe_harbor": true

Logo resources

The readme talks about "Organizations displaying the disclose.io logo". However there don't seem to be any resources where you can easily get the logo from. It is possible go the main site and extract the SVG if you're dedicated enough. Would it be worthwhile including the logo in small range of formats in this repo?

s/harbor/harbour/g for Canada terms

I believe that for the Canadian draft of terms, we should use the spelling "harbour" in the expression "safe harbour".

Note that I'm not Canadian, and am not fully certain of the spelling of "safe harbou?r" in Canadian legal language.

Issue with "keeping vulnerabilities confidential"

Keep the details of any discovered vulnerabilities confidential until they are fixed, according to the Disclosure Policy;
- https://github.com/disclose/disclose/blob/master/terms/core-terms-USA/core-terms-USA.md

As a researcher I would like to retain my ability to hold companies to 90 day disclosure deadlines in line with the Google Project Zero policy.

This 'term' both means that companies can both sit on vulnerabilities and prevent disclosure by not fixing them, or they can also close them as 'out of scope' and then forbid disclosure as well. How can we convey that both of these behaviours are unacceptable.

I went public with the Zoom vulnerability after it wasn't fixed in 90 days, similarly, Valve has been facing backlash over it's closing a Local Privilege Escalation bug as 'out of scope' then evicting a researcher from their program.

This line doesn't seem to allow for either of these two use cases.

Review & Reconciliation of Blockchain Commons Security Services Contract?

Blockchain Commons is an open infrastructure organization that both offers security review services (largely security architecture reviews and risk/threat models, but rarely code reviews), and will be asking others to review our own code.

In spirit of open development, in addition of sharing our code, we are also sharing our best practices and legal templates. We have just released the first draft of our "security services contract" https://github.com/BlockchainCommons/Open-Development/tree/master/security-services-contract which is intended to be used in future contracts by others of us, but also when we ask others to review our work.

I'd very much be interested in reconciling our contract with the language and concerns of raised by this community, and thus improve it for use by our community. Issues and PRs welcome!

Proper 404 Checking

Fastest way I know to fetch head and disconenct, over 80 and 443:

[user@hostname ~]$ curl --head --silent 'https://www.facebook.com/security.txt'
HTTP/2 200 
vary: Accept-Encoding
content-type: text/plain;charset=utf-8
report-to: {"max_age":3600,"endpoints":[{"url":"https:\/\/www.facebook.com\/ajax\/browser_error_reports\/?device_level=unknown"}],"group":"network-errors"}
x-fb-rlafr: 0
document-policy: force-load-at-top
cross-origin-resource-policy: same-origin
nel: {"report_to":"network-errors","max_age":3600,"failure_fraction":0.01}
pragma: no-cache
cache-control: private, no-cache, no-store, must-revalidate
expires: Sat, 01 Jan 2000 00:00:00 GMT
x-content-type-options: nosniff
x-xss-protection: 0
x-frame-options: DENY
strict-transport-security: max-age=15552000; preload
date: Sat, 15 Jan 2022 17:01:40 GMT
priority: u=3,i
alt-svc: h3=":443"; ma=3600, h3-29=":443"; ma=3600

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.