Fix github links

PiperOrigin-RevId: 623476933

README.md

@@ -24,22 +24,22 @@ To build SCALIBR, you'll need to have the following installed:
 1. `make`
 1. `./scalibr --result=result.textproto`
 
-See the [result proto definition](binary/proto/scan_result.proto) for details about the scan result format.
+See the [result proto definition](/binary/proto/scan_result.proto) for details about the scan result format.
 
 Run `./scalibr --help` for a list of additional CLI args.
 
 ### As a library:
 1. Import `github.com/google/osv-scalibr` into your Go project
 1. Write a custom implementation for the `fs.FS` interface, or use an existing one like `os.DirFS`
-1. Create a new [scalibr.ScanConfig](scalibr.go#L36) struct, configure the extraction and detection plugins to run
+1. Create a new [scalibr.ScanConfig](/scalibr.go#L36) struct, configure the extraction and detection plugins to run
 1. Call `scalibr.New().Scan()` with the config and the FS implementation
-1. Parse the returned [scalibr.ScanResults](scalibr.go#L50)
+1. Parse the returned [scalibr.ScanResults](/scalibr.go#L50)
 
 See below for an example code snippet.
 
 ### On a container image
 
-See the [run_scalibr_on_image.sh](run_scalibr_on_image.sh) script for an example of how to run SCALIBR on container images.
+See the [run_scalibr_on_image.sh](/run_scalibr_on_image.sh) script for an example of how to run SCALIBR on container images.
 
 ### SPDX generation
 
@@ -58,10 +58,10 @@ Some fields in the generated SPDX can be overwritten:
 ## Running built-in plugins
 
 ### With the standalone binary
-The binary runs SCALIBR's "recommended" internal plugins by default. You can enable more plugins with the `--extractors=` and `--detectors=` flags. See the the definition files for a list of all built-in plugins and their CLI flags ([extractors](extractor/list/list.go#L26), [detectors](detector/list/list.go#L26)).
+The binary runs SCALIBR's "recommended" internal plugins by default. You can enable more plugins with the `--extractors=` and `--detectors=` flags. See the the definition files for a list of all built-in plugins and their CLI flags ([extractors](/extractor/list/list.go#L26), [detectors](/detector/list/list.go#L26)).
 
 ### With the library
-A collection of all built-in plugin modules can be found in the definition files ([extractors](extractor/list/list.go#L26), [detectors](detector/list/list.go#L26)). To enable them, just import the module and add the appropriate plugins to the scan config, e.g.
+A collection of all built-in plugin modules can be found in the definition files ([extractors](/extractor/list/list.go#L26), [detectors](/detector/list/list.go#L26)). To enable them, just import the module and add the appropriate plugins to the scan config, e.g.
 
 ```
 import (
@@ -80,7 +80,7 @@ results := scalibr.New().Scan(context.Background(), cfg)
 ## Creating + running custom plugins
 Custom plugins can only be run when using SCALIBR as a library.
 
-1. Create an implementation of the SCALIBR [Extractor](extractor/extractor.go#L30) or [Detector](detector/detector.go#L28) interface.
+1. Create an implementation of the SCALIBR [Extractor](/extractor/extractor.go#L30) or [Detector](/detector/detector.go#L28) interface.
 2. Add the newly created struct to the scan config and run the scan, e.g.
 
 ```
@@ -96,7 +96,7 @@ results := scalibr.New().Scan(context.Background(), cfg)
 ```
 
 ## Custom logging
-You can make the  SCALIBR library log using your own custom logger by passing an implementation of the [`log.Logger`](log/log.go#L22) interface to `log.SetLogger()`:
+You can make the  SCALIBR library log using your own custom logger by passing an implementation of the [`log.Logger`](/log/log.go#L22) interface to `log.SetLogger()`:
 
 ```
 import (

detector/detector.go

@@ -123,7 +123,7 @@ type TargetDetails struct {
 	Location []string
 }
 
-// LINT.ThenChange(binary/proto/scan_result.proto)
+// LINT.ThenChange(/binary/proto/scan_result.proto)
 
 // Run runs the specified detectors and returns their findings,
 // as well as info about whether the plugin runs completed successfully.

docs/new_detector.md

@@ -10,19 +10,19 @@ interface and have read access to all files on the filesystem through it.
 
 ## Steps for writing a new detector
 
-See the [CIS benchmark detector](detector/cis/generic_linux/etcpasswdpermissions/detector.go) as an example.
+See the [CIS benchmark detector](/detector/cis/generic_linux/etcpasswdpermissions/detector.go) as an example.
 
 1.  Set up your detector package in an [appropriate location](#code-location).
 1.  Create a struct that implements
-    [`Detector`](detector/detector.go):
+    [`Detector`](/detector/detector.go):
     *   Implement `Name()` to return a unique name, e.g. `cve/nginxldapauth`.
     *   Implement `Version()` to return 0. Increase it in the future whenever
         larger changes are made to the detector.
     *   Implement `Scan()` (see [param list](#scan-parameters)) to run your
         detection logic and [return](#output-format) the security findings.
 1.  Write tests.
 1.  Register your detector in
-    [list.go](detector/list/list.go)
+    [list.go](/detector/list/list.go)
     so you can use it in the CLI.
 1.  Test your new detector on a local machine, using the plugin `Name()` to
     enable it, e.g.
@@ -32,20 +32,20 @@ See the [CIS benchmark detector](detector/cis/generic_linux/etcpasswdpermissions
     ```
 
     See the
-    [README](README.md#as-a-standalone-binary)
+    [README](/README.md#as-a-standalone-binary)
     for more details on how to run SCALIBR locally.
 
 1.  Submit your code for review.
 
 Once your code is merged, you can add your detector to the list of available
 detectors in
-[detector/list/list.go](detector/list/list.go).
+[detector/list/list.go](/detector/list/list.go).
 Please submit this code separately from the main detector logic.
 
 ## Code location
 
 All new detectors should be in a sub-folder of
-[detector/](detector/).
+[detector/](/detector/).
 If there's already a directory that fits the detector's category (e.g. cis)
 place it in there. Otherwise, feel free to create a new directory.
 
@@ -64,18 +64,18 @@ changes to the target machine.
 ### Inventory index
 
 Detectors also receive an
-[`InventoryIndex`](inventoryindex/inventory_index.go)
+[`InventoryIndex`](/inventoryindex/inventory_index.go)
 param that can be used to query the software inventory that the extraction step
 found on the filesystem. This can be used to run the detection logic on each relevant
 software found, or exit early if none are installed. For an example use case see the
-[govulncheck Detector](detector/govulncheck/binary/detector.go).
+[govulncheck Detector](/detector/govulncheck/binary/detector.go).
 
 ## Output format
 
 Detectors return their vulnerability findings in the
-[`Finding`](detector/detector.go#L46)
+[`Finding`](/detector/detector.go#L46)
 struct. See the comments in the `Finding` struct and
-[existing Detector implementations](detector/govulncheck/binary/detector.go)
+[existing Detector implementations](/detector/govulncheck/binary/detector.go)
 for guidance on how to fill it out. Keep in mind that findings are uniquely
 identified by the `AdvisoryID` and each detector should return a unique
 `AdvisoryID` for their findings.

docs/new_extractor.md

@@ -7,7 +7,7 @@ There should be one Extractor per parsing logic. In python for example there are
 multiple files to represent installed packages. `PKG-INFO`, `egg-info` and
 `METADATA` have the same format (MIME type) and therefore same parsing logic.
 Therefore there is one extractor
-([wheelegg](extractor/language/python/wheelegg/extractor.go))
+([wheelegg](/extractor/language/python/wheelegg/extractor.go))
 for all of them. `.egg` files are zip files which contain one of the previously
 mentioned files, thus `.egg` is also handled by this extractor. On the other
 side, there are files which have a different format, e.g. `requirements.txt`,
@@ -29,15 +29,15 @@ requirements/ <- extractor
 ## What you need to implement
 
 They have to implement the
-[InventoryExtractor](extractor/extractor.go#L34)
+[InventoryExtractor](/extractor/extractor.go#L34)
 interface.
 
 # See extractor/extractor.go symbol InventoryExtractor
 
 # See plugin/plugin.go symbol Plugin
 
 Here is a simplified version of how SCALIBR will call the extractor like this
-([actual code](extractor/extractor.go#L86)):
+([actual code](/extractor/extractor.go#L86)):
 
 ```
 for f in walk.files:
@@ -58,15 +58,15 @@ will take care of this.
 ## Input
 
 SCALIBR will call `Extract` with
-[ScanInput](extractor/extractor.go#L50),
+[ScanInput](/extractor/extractor.go#L50),
 which contains the path, `fs.FileInfo` and `io.Reader` for the file.
 
 # See extractor/extractor.go symbol ScanInput
 
 ## Output
 
 The `Extract` method should return a list of
-[Inventory](extractor/extractor.go#L63).
+[Inventory](/extractor/extractor.go#L63).
 
 # See extractor/extractor.go symbol extractor.Inventory\b
 
@@ -76,27 +76,27 @@ multiple Inventory entries in case there are multiple in one file.
 ## Code location
 
 Extractors should be in a sub folder of
-[/extractor/](extractor/)
+[/extractor/](/extractor/)
 
 Use this decision tree to identify where to add the extractor.
 
 -   Is the extractor for a specific language? (Java, Go, Python, etc)
     -   **Yes**: Add the extractor under
-        [extractor/language/](extractor/language/)
+        [extractor/language/](/extractor/language/)
         using the format: `language/[LANGUAGE]/[EXTRACTION_TARGET]`. For
         example, the location for a JavaScript
         [`package.json`](https://docs.npmjs.com/cli/v9/configuring-npm/package-json)
         extractor would be
-        [`language/javascript/packagejson/`](extractor/language/javascript/packagejson/).
+        [`language/javascript/packagejson/`](/extractor/language/javascript/packagejson/).
 -   Is the extractor for an OS or OS package manager? (Debian, Linux, etc)
     -   **Yes**: Add the extractor under
-        [extractor/os](extractor/os)
+        [extractor/os](/extractor/os)
         using the format: `os/[PACKAGE_MANAGER]`. For example, the location for
         a Debian based [dpkg](https://man7.org/linux/man-pages/man1/dpkg.1.html)
         extractor would be `os/dpkg`.
 -   Is the extractor for an SBOM format? (SPDX, etc)
     -   **Yes**: Add the extractor under
-        [extractor/sbom/](extractor/sbom/)
+        [extractor/sbom/](/extractor/sbom/)
         using the format: `sbom/[FORMAT]/`. For example, the location for an
         [SPDX](https://spdx.dev/) file extractor would be `sbom/spdx`.
 -   Is the extractor for something else?
@@ -105,7 +105,7 @@ Use this decision tree to identify where to add the extractor.
 
 ## Step by step
 
-You can take the [package.json](extractor/language/javascript/packagejson/extractor.go)
+You can take the [package.json](/extractor/language/javascript/packagejson/extractor.go)
 extractor as an example.
 
 1.  Implement `Name()` to return a unique name. Best practice is to use the path
@@ -124,7 +124,7 @@ extractor as an example.
 1.  Write tests (you can separate tests for FileRequired and Extract, to avoid
     having to give test data specific file names).
 1.  Register your extractor in
-    [list.go](extractor/list/list.go)
+    [list.go](/extractor/list/list.go)
 1.  Optional: test locally, use the name of the extractor given by `Name()` to
     select your extractor. For the `packagejson` extractor it would look like
     this:
@@ -134,13 +134,13 @@ extractor as an example.
     ```
 
     You can find more details on how to run scalibr in
-    [README.md](README.md#as-a-standalone-binary)
+    [README.md](/README.md#as-a-standalone-binary)
 
 1.  Submit your code for review. Once merged, the extractor is ready to use, but
     not activated in any defaults yet.
 
 To add your extractor to the list of default extractors, add it in
-[extractor/list/list.go](extractor/list/list.go).
+[extractor/list/list.go](/extractor/list/list.go).
 Please submit this code separately from the main extractor logic.
 
 In case you have any questions or feedback, feel free to open an issue.

extractor/extractor.go

@@ -101,7 +101,7 @@ type Inventory struct {
 	Metadata any
 }
 
-// LINT.ThenChange(binary/proto/scan_result.proto)
+// LINT.ThenChange(/binary/proto/scan_result.proto)
 
 // Run runs the specified extractors and returns their extraction results,
 // as well as info about whether the plugin runs completed successfully.

extractor/list/list.go

@@ -119,7 +119,7 @@ var (
 	}
 )
 
-// LINT.ThenChange(docs/supported_inventory_types.md)
+// LINT.ThenChange(/docs/supported_inventory_types.md)
 
 func init() {
 	for _, e := range append(All, Untested...) {

plugin/plugin.go

@@ -51,7 +51,7 @@ const (
 	ScanStatusFailed
 )
 
-// LINT.ThenChange(binary/proto/scan_result.proto)
+// LINT.ThenChange(/binary/proto/scan_result.proto)
 
 // StatusFromErr returns a successful or failed plugin scan status for a given plugin based on an error.
 func StatusFromErr(p Plugin, partial bool, err error) *Status {

scalibr.go

@@ -71,7 +71,7 @@ type ScanResult struct {
 	Findings     []*detector.Finding
 }
 
-// LINT.ThenChange(binary/proto/scan_result.proto)
+// LINT.ThenChange(/binary/proto/scan_result.proto)
 
 // Scan executes the extraction and detection using the provided scan config.
 func (Scanner) Scan(ctx context.Context, config *ScanConfig) (sr *ScanResult) {