fix: update repository URLs from intel to ossf

Update all references from github.com/intel/cve-bin-tool to
github.com/ossf/cve-bin-tool across documentation, source code,
templates, SBOMs, and test files.

fixes #5451

Author: jackulau

.github/ISSUE_TEMPLATE/docstrings.md

@@ -50,8 +50,8 @@ pre-commit install --hook-type pre-commit --hook-type commit-msg
 
 **Short tips for new contributors:**
 
-* [cve-bin-tool's contributor docs](https://github.com/intel/cve-bin-tool/blob/main/CONTRIBUTING.md)
-* If you've contributed to open source but not this project, you might just want our [checklist for a great pull request](https://github.com/intel/cve-bin-tool/blob/main/CONTRIBUTING.md#checklist-for-a-great-pull-request)
+* [cve-bin-tool's contributor docs](https://github.com/ossf/cve-bin-tool/blob/main/CONTRIBUTING.md)
+* If you've contributed to open source but not this project, you might just want our [checklist for a great pull request](https://github.com/ossf/cve-bin-tool/blob/main/CONTRIBUTING.md#checklist-for-a-great-pull-request)
 * cve-bin-tool uses <https://www.conventionalcommits.org/> style for commit messages, and we have a test that checks the title of your pull request (PR).  A good potential title for this one is in the title of this issue.
 * You can make an issue auto close by including a comment "fixes #ISSUENUMBER" in your PR comments where ISSUENUMBER is the actual number of the issue.  This "links" the issue to the pull request.
 

.github/ISSUE_TEMPLATE/feat--new-checker-request-form.md

@@ -18,7 +18,7 @@ Many older products may have multiple NVD CPE  {vendor, product} pairs associate
 
 
 ### Checker creation links
-Instructions: [How to add a new checker to the CVE Binary Tool](https://github.com/intel/cve-bin-tool/blob/master/cve_bin_tool/checkers/README.md)
+Instructions: [How to add a new checker to the CVE Binary Tool](https://github.com/ossf/cve-bin-tool/blob/master/cve_bin_tool/checkers/README.md)
 
-We also have a [checker creation helper script](https://github.com/intel/cve-bin-tool/blob/main/cve_bin_tool/helper_script.py) that can get you started in making the checker.
-* [Helper script documentation](https://github.com/intel/cve-bin-tool/blob/main/cve_bin_tool/checkers/README.md#helper-script)
+We also have a [checker creation helper script](https://github.com/ossf/cve-bin-tool/blob/main/cve_bin_tool/helper_script.py) that can get you started in making the checker.
+* [Helper script documentation](https://github.com/ossf/cve-bin-tool/blob/main/cve_bin_tool/checkers/README.md#helper-script)

.github/ISSUE_TEMPLATE/mismatch-report.md

@@ -23,5 +23,5 @@ Not sure how to fill this out? Give us the CVE number that's being incorrectly d
 
 ### Instructions
 
-[How to add a new entry to the mismatch database](https://github.com/intel/cve-bin-tool/blob/main/doc/mismatch_data.md)
+[How to add a new entry to the mismatch database](https://github.com/ossf/cve-bin-tool/blob/main/doc/mismatch_data.md)
 

CONTRIBUTING.md

@@ -48,7 +48,7 @@ The contribution guidelines outline the process that you'll need to follow to ge
 
 And you don't just have to write code. You can help out by writing documentation, tests, or even by giving feedback about this work. (And yes, that includes giving feedback about the contribution guidelines.)
 
-If have questions or want to chat, we have a [gitter chat room](https://gitter.im/cve-bin-tool/community) where you can ask questions, or you can put them in [GitHub issues](https://github.com/intel/cve-bin-tool/issues) too.
+If have questions or want to chat, we have a [gitter chat room](https://gitter.im/cve-bin-tool/community) where you can ask questions, or you can put them in [GitHub issues](https://github.com/ossf/cve-bin-tool/issues) too.
 
 Thank you for contributing!
 
@@ -71,7 +71,7 @@ There are lots of different ways to use git, and it's so easy to get into a mess
 
 If you're planning to contribute, first you'll want to [get a local copy of the source code (also known as "cloning the repository")](https://help.github.com/en/github/creating-cloning-and-archiving-repositories/cloning-a-repository)
 
-`git clone [email protected]:intel/cve-bin-tool.git`
+`git clone [email protected]:ossf/cve-bin-tool.git`
 
 Once you've got the copy, you can update it using
 
@@ -191,7 +191,7 @@ python -m pytest
 
 This bypasses potential issues with your system's PATH environment variable, potentially looking in the wrong directory for the dependencies.
 
-[There is a README file in the tests directory](https://github.com/intel/cve-bin-tool/blob/main/test/README.md) which contains more info about how to run specific tests, or how to run the longer tests.
+[There is a README file in the tests directory](https://github.com/ossf/cve-bin-tool/blob/main/test/README.md) which contains more info about how to run specific tests, or how to run the longer tests.
 
 We have done our best to make tests stable and ensure that they pass at all times, but occasionally tests may fail due to factors outside your control (common causes: internet connectivity, rate limiting by NVD or new vulnerability data changing our test expectations). If a test doesn't pass, you should look at it to see if any changes you made caused the failure.  If you're not sure, submit your code as a pull request and mention the issue and someone will try to help you sort it out.
 
@@ -316,7 +316,7 @@ interrogate -vv -i -I -M -C -n -p -f 60.0 -e fuzz/ -e test/ -e cve_bin_tool/chec
 ```
 You can specify a file or directory if you just want to check the files you changed.  
 
-Interrogate shows some [report examples in their docs](https://interrogate.readthedocs.io/en/latest/#usage) or you can look at the [current cve-bin-tool reports in our linter runs on GitHub Actions](https://github.com/intel/cve-bin-tool/actions/workflows/linting.yml)
+Interrogate shows some [report examples in their docs](https://interrogate.readthedocs.io/en/latest/#usage) or you can look at the [current cve-bin-tool reports in our linter runs on GitHub Actions](https://github.com/ossf/cve-bin-tool/actions/workflows/linting.yml)
 
 ### Running codespell by itself
 
@@ -340,17 +340,17 @@ As well as `black` for automatically making sure code adheres to the style guide
 
 We use [pyupgrade](https://github.com/asottile/pyupgrade) to make sure our syntax is updated to fit new versions of python.
 
-We also have a spell checker set up to help us avoid typos in documentation.  The [spelling actions readme file](https://github.com/intel/cve-bin-tool/tree/main/.github/actions/spelling) gives more information including how to add new words to the dictionary if needed.
+We also have a spell checker set up to help us avoid typos in documentation.  The [spelling actions readme file](https://github.com/ossf/cve-bin-tool/tree/main/.github/actions/spelling) gives more information including how to add new words to the dictionary if needed.
 
-We also have a tool to help make sure that new checkers are added to the tables in our documentation and relevant words associated with checker names are put in allow dictionary for spelling checks, this is done automatically with GitHub actions. [The format_checkers code is here](https://github.com/intel/cve-bin-tool/blob/main/cve_bin_tool/format_checkers.py), if you're curious.
+We also have a tool to help make sure that new checkers are added to the tables in our documentation and relevant words associated with checker names are put in allow dictionary for spelling checks, this is done automatically with GitHub actions. [The format_checkers code is here](https://github.com/ossf/cve-bin-tool/blob/main/cve_bin_tool/format_checkers.py), if you're curious.
 
-You can view all the config files for GitHub Actions (what we use for Continuous Integration (CI)) in [the .github/workflows directory](https://github.com/intel/cve-bin-tool/tree/main/.github/workflows).
+You can view all the config files for GitHub Actions (what we use for Continuous Integration (CI)) in [the .github/workflows directory](https://github.com/ossf/cve-bin-tool/tree/main/.github/workflows).
 
 ## Making a new branch & pull request
 
 Git allows you to have "branches" with variant versions of the code.  You can see what's available using `git branch` and switch to one using `git checkout branch_name`.
 
-To make your life easier, we recommend that the `main` branch always be kept in sync with the repo at `https://github.com/intel/cve-bin-tool`, as in you never check in any code to that branch.  That way, you can use that "clean" main branch as a basis for each new branch you start as follows:
+To make your life easier, we recommend that the `main` branch always be kept in sync with the repo at `https://github.com/ossf/cve-bin-tool`, as in you never check in any code to that branch.  That way, you can use that "clean" main branch as a basis for each new branch you start as follows:
 
 ```bash
 git checkout main
@@ -383,7 +383,7 @@ Once your branch is ready and you've checked in all your code, push it to your f
 git push myfork
 ```
 
-From there, you can go to [our pull request page](https://github.com/intel/cve-bin-tool/pulls) to make a new pull request from the web interface.
+From there, you can go to [our pull request page](https://github.com/ossf/cve-bin-tool/pulls) to make a new pull request from the web interface.
 
 ### Checklist for a great pull request
 
@@ -399,7 +399,7 @@ Here's a quick checklist to help you make sure your pull request is ready to go:
 3. Have I added any tests I need to prove that my code works?
    - This is especially important for new features or new checkers.
 4. Have I added or updated any documentation if I changed or added a feature?
-   - New features are often documented in [MANUAL.md](https://github.com/intel/cve-bin-tool/blob/main/doc/MANUAL.md).  (See [Making documentation](#making-documentation) for more information.)
+   - New features are often documented in [MANUAL.md](https://github.com/ossf/cve-bin-tool/blob/main/doc/MANUAL.md).  (See [Making documentation](#making-documentation) for more information.)
 5. Have I used [Conventional Commits](https://www.conventionalcommits.org/) to format the title of my pull request?
 6. If I closed a bug, have I linked it using one of [GitHub's keywords](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)? (e.g. include the text `fixed #1234`)
 7. Have I checked on the results from GitHub Actions?
@@ -418,7 +418,7 @@ If something needs fixing or we have questions, we'll work back and forth with y
 
 Once any issues are resolved, we'll merge your code.  Yay!
 
-In rare cases, the code won't work for us and we'll let you know.  Sometimes this happens because someone else has already submitted a fix for the same bug, (Issues marked [good first issue](https://github.com/intel/cve-bin-tool/labels/good%20first%20issue) can be in high demand!) or because you worked on a checker that didn't have a good signature. Don't worry, these things happens, no one thinks less of you for trying!
+In rare cases, the code won't work for us and we'll let you know.  Sometimes this happens because someone else has already submitted a fix for the same bug, (Issues marked [good first issue](https://github.com/ossf/cve-bin-tool/labels/good%20first%20issue) can be in high demand!) or because you worked on a checker that didn't have a good signature. Don't worry, these things happens, no one thinks less of you for trying!
 
 ## Style Guide for cve-bin-tool
 
@@ -487,9 +487,9 @@ Many beginners get stuck trying to figure out how to start.  You're not alone!
 
 Here's three things we recommend:
 
-1. Try something marked as a "[good first issue](https://github.com/intel/cve-bin-tool/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)" We try to mark issues that might be easier for beginners.
-2. [Add tests to an existing checker](https://github.com/intel/cve-bin-tool/blob/main/test/README.md). This will give you some practice with the test suite.
-3. [Add a new checker](https://github.com/intel/cve-bin-tool/blob/main/cve_bin_tool/checkers/README.md)  This will give you some deeper understanding of how the tool works and what a signature looks like.  We have a few new checker requests listed in the "good first issue" list, or any linux library that has known CVEs (preferably recent ones) is probably interesting enough.
+1. Try something marked as a "[good first issue](https://github.com/ossf/cve-bin-tool/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)" We try to mark issues that might be easier for beginners.
+2. [Add tests to an existing checker](https://github.com/ossf/cve-bin-tool/blob/main/test/README.md). This will give you some practice with the test suite.
+3. [Add a new checker](https://github.com/ossf/cve-bin-tool/blob/main/cve_bin_tool/checkers/README.md)  This will give you some deeper understanding of how the tool works and what a signature looks like.  We have a few new checker requests listed in the "good first issue" list, or any linux library that has known CVEs (preferably recent ones) is probably interesting enough.
 4. Suggest fixes for documentation.  If you try some instruction and it doesn't work, or you notice a typo, those are always easy first commits!  One place we're a bit weak is instructions for Windows users.
 
 If you get stuck or find something that you think should work but doesn't, ask for help in an issue or stop by [the cve-bin-tool gitter](https://gitter.im/cve-bin-tool/community) to ask questions.