chore: fix documentation links (#487)

docs/dependency-updates.md

@@ -1,9 +1,11 @@
 # Dependency Updates
 
 ## Responsibility
-Dependency updates are a responsibility of all project maintainers. All maintainers must be accountable for the updates they introduce and proper review provides a mechanism for reducing the potential for negative impact to the project. 
+
+Dependency updates are a responsibility of all project maintainers. All maintainers must be accountable for the updates they introduce and proper review provides a mechanism for reducing the potential for negative impact to the project.
 
 ## Objectives
+
 - Ensuring that all dependencies are updated to their latest versions
 - Understanding the implications of updated dependency code
 - Validating the provenance of the updated dependency
@@ -31,26 +33,33 @@ Through the use of [Renovate](https://www.mend.io/renovate/), we can automate th
 ## Examples
 
 ### Golang Dependencies
+
 Given a dependency in the go.mod file, the following steps are taken to validate the dependency:
+
 1. Identify the dependency source - IE github.com/open-policy-agent/opa
 2. Identify the tagged version - IE v0.62.1
-3. Curl the checksum of the tagged version - IE curl https://sum.golang.org/lookup/${source}@${tag}
+3. Curl the checksum of the tagged version - IE curl `https://sum.golang.org/lookup/${source}@${tag}`
 
 The following should be returned for use in validation:
+
 ```
 github.com/open-policy-agent/opa v0.62.1 h1:UcxBQ0fe6NEjkYc775j4PWoUFFhx4f6yXKIKSTAuTVk=
 github.com/open-policy-agent/opa v0.62.1/go.mod h1:YqiSIIuvKwyomtnnXkJvy0E3KtVKbavjPJ/hNMuOmeM=
 ```
 
 ### NPM Dependencies
+
 Given a dependency in the package-lock.json file, the following steps are taken to validate the dependency:
+
 1. Identify the resolved dependency archive - IE https://registry.npmjs.org/autoprefixer/-/autoprefixer-10.4.19.tgz
 2. Curl the archive locally - IE curl -LO https://registry.npmjs.org/autoprefixer/-/autoprefixer-10.4.19.tgz
 3. Perform a SHA512 hash on the archive - IE cat ./autoprefixer-10.4.19.tgz | openssl dgst -sha512 -binary | openssl base64 -A
 4. Compare results against the `integrity` field in the package-lock.json file
 
 ### GitHub Action Dependencies
-Review the updated commit hash of the tagged action against the tag of the action in the source git repository. 
+
+Review the updated commit hash of the tagged action against the tag of the action in the source git repository.
 
 ### Notes
-- Validation of the checksums is currently a manual process and a byproduct of not yet capturing the provenance of Renovates checksum process. Given that no single version of Renovate is being used (this is the non-self-hosted GitHub application), we do not track updates to the renovate runtime itself. 
+
+- Validation of the checksums is currently a manual process and a byproduct of not yet capturing the provenance of Renovates checksum process. Given that no single version of Renovate is being used (this is the non-self-hosted GitHub application), we do not track updates to the renovate runtime itself.

docs/oscal-validation-links.md

@@ -8,8 +8,10 @@
     - [Remote Validations](#remote-validations)
     - [Checksums](#checksums)
     - [Multiple Validations](#multiple-validations)
+
 ___
 In OSCAL - `links` contains the following fields:
+
 ```yaml
 links:
   - href: https://www.example.com/
@@ -21,7 +23,7 @@ links:
 
 These links are a "reference to a local or remote resource, that has a specific relation to the containing object" - [Component Definition Links](https://pages.nist.gov/OSCAL-Reference/models/v1.1.2/component-definition/json-reference/#/component-definition/components/links).
 
-As such, links are a native OSCAL attribute that Lula can use to map to Validations. 
+As such, links are a native OSCAL attribute that Lula can use to map to Validations.
 
 ## Connecting Links with Lula Validations
 
@@ -60,12 +62,14 @@ back-matter:
             }
 ```
 
-Now we need to map an existing control (or Component-Definition Implemented-Requirement) to this Lula Validation. 
+Now we need to map an existing control (or Component-Definition Implemented-Requirement) to this Lula Validation.
 
 ### Rel
+
 The default workflow is to use the rel attribute to indicate that Lula has work to perform.
 
 In the instance of a standard validation - A link to a Lula Validation might look like this:
+
 ```yaml
 links:
   - href: '#a7377430-2328-4dc4-a9e2-b3f31dc1dff9'
@@ -75,16 +79,18 @@ links:
 Where `href: '#a7377430-2328-4dc4-a9e2-b3f31dc1dff9'` points to an OSCAL object with a UUID reference and `rel: lula` indicates that the link is to a Lula Validation.
 UUID's should always be unique per object in the OSCAL artifact.
 
-
 > [!TIP]
 > You can generate a random UUID using `lula tools uuidgen` or a deterministic UUID using `lula tools uuidgen <string>`.
 
 ## Importing Validations
+
 In addition to storing validaitons in the `BackMatter`, `links` may be used to fetch resources external to the `component-definition`.
 
 ### Local Validations
+
 - must be prefixed with `file:`
 - `file:` must be a relative path to the `component-definition` or an absolute path
+
 ```yaml
 links:
   - href: file:./validation.yaml
@@ -94,28 +100,34 @@ links:
 ```
 
 ### Remote Validations
+
 - must be prefixed with `https:` or `http:`
 - `https:` or `http:` must be a valid URL
+
 ```yaml
 links:
   - href: https://example.com/validation.yaml
     rel: lula
 ```
 
 ### Checksums
-- A checksum may be provided in the href using the suffix `@<checksum>` 
+
+- A checksum may be provided in the href using the suffix `@<checksum>`
 - Supports `sha1`, `sha256`, `sha512`, `md5`
+
 ```yaml
 links:
   - href: https://example.com/validation.yaml@0123456789abcdef
     rel: lula
 ```
 
-### Multiple Validations 
+### Multiple Validations
+
 - A file with multiple validations may be provided in the link.
 - `---` should be used to separate each validation
 - `resource-fragment: <UUID>` will run the validation with the UUID specified
 - `resource-fragment: *` will run all validations
+
 ```yaml
 // Only runs the validation with the UUID of a7377430-2328-4dc4-a9e2-b3f31dc1dff9
 links:
@@ -127,6 +139,7 @@ links:
     rel: lula
     resource-fragment: *
 ```
-___ 
+
+___
 > [!NOTE]
-> An example `component-definition` with remote validations can be found [here](../src/test/e2e/scenarios/remote-validations/component-definition.yaml).
+> An example `component-definition` with remote validations can be found [here](https://github.com/defenseunicorns/lula/blob/main/src/test/e2e/scenarios/remote-validations/component-definition.yaml).

docs/release-process.md

@@ -8,7 +8,7 @@ This project uses [goreleaser](https://github.com/goreleaser/goreleaser-action)
 
 ### How should I write my commits?
 
-We use conventional commit messages [Conventional Commit messages](https://www.conventionalcommits.org/). 
+We use conventional commit messages [Conventional Commit messages](https://www.conventionalcommits.org/).
 
 The most important prefixes you should have in mind are:
 
@@ -21,7 +21,7 @@ The most important prefixes you should have in mind are:
 ### How can I influence the version number for a release?
 
 PR titles should also follow this pattern and are linted using [commitlint](https://commitlint.js.org/). The PR title will determine the version bump. When a PR is merged (squashed) release-please will kick off a release PR. When that release PR is approved and merged, release-please will create a draft release. Once that draft release is published go-releaser with build and publish the assets.  
-* Pre-v1.0.0 release-please is configured to bump minors on breaking changes and patches otherwise. per [release-please-config](../release-please-config.json)
+- Pre-v1.0.0 release-please is configured to bump minors on breaking changes and patches otherwise. per [release-please-config](https://github.com/defenseunicorns/lula/blob/main/release-please-config.json)
 
 ### How do I fix a release issue?