Merge pull request #11 from smithy-security/feature/docs-after-new-ma…

…rketing-site

Freshen up the docs with new designs

.gitignore

@@ -18,3 +18,4 @@
 npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
+.idea/*

README.md

@@ -5,7 +5,7 @@ This website is built using [Docusaurus](https://docusaurus.io/), a modern stati
 ## Installation
 
 ```bash
-yarn
+yarn install
 ```
 
 ## Local Development

docs/explanation/pipelines.md

@@ -1,3 +1 @@
-# Pipelines
-
-TODO
+todo

docs/how-tos/components/advanced.md

@@ -8,11 +8,11 @@ sidebar_position: 4
 
 All `.go` components get built using a default Docker image. If you want to use your own image, for example, because your component has custom dependencies, you can do that too.
 
-One good example of such a component is the [producers/ossf-scorecard component](https://github.com/ocurity/dracon/tree/main/components/producers/ossf-scorecard). Let's take a closer look at it.
+One good example of such a component is the [producers/ossf-scorecard component](https://github.com/smithy-security/smithy/tree/main/components/producers/ossf-scorecard). Let's take a closer look at it.
 
-In the below `Dockerfile` we using a custom base image and then are further configuring that.
+In the below `Dockerfile` we're using a custom base image and then are further configuring that.
 
-```docker title="dracon/components/producers/ossf-scorecard/Dockerfile"
+```docker title="smithy/components/producers/ossf-scorecard/Dockerfile"
 ARG OSSF_SCORECARD_SAFETY_BASE_IMAGE
 FROM gcr.io/openssf/scorecard:stable
 
@@ -25,23 +25,23 @@ ENTRYPOINT ["/scorecard"]
 
 In addition, a `Makefile` is placed inside the component folder, to advice Smithy on how to build the component image.
 
-```makefile title="dracon/components/producers/ossf-scorecard/Makefile"
+```makefile title="smithy/components/producers/ossf-scorecard/Makefile"
 .PHONY: component publish
 
 CONTAINER_REPO=
-DRACON_VERSION=
+SMITHY_VERSION=
 OSSF_SCORECARD_SAFETY_BASE_IMAGE=$(shell test -e .custom_image && cat .custom_image || echo "alpine:latest")
 
 DOCKER=docker
 
 component:
-	$(DOCKER) build --tag $(CONTAINER_REPO)/components/producers/ossf-scorecard:$(DRACON_VERSION) \
+	$(DOCKER) build --tag $(CONTAINER_REPO)/components/producers/ossf-scorecard:$(SMITHY_VERSION) \
 					--file Dockerfile \
 					$$([ "${SOURCE_CODE_REPO}" != "" ] && echo "--label=org.opencontainers.image.source=${SOURCE_CODE_REPO}" ) \
 					--build-arg OSSF_SCORECARD_SAFETY_BASE_IMAGE=$(OSSF_SCORECARD_SAFETY_BASE_IMAGE) ../../.. 1>&2
 
 publish:
-	$(DOCKER) push $(CONTAINER_REPO)/components/producers/ossf-scorecard:$(DRACON_VERSION) 1>&2
+	$(DOCKER) push $(CONTAINER_REPO)/components/producers/ossf-scorecard:$(SMITHY_VERSION) 1>&2
 ```
 
 And that's it! Simply by adding these two files Smithy will now be able to build your component.

docs/how-tos/components/example-producer/main.go

@@ -5,9 +5,9 @@ import (
 	"fmt"
 	"log"
 
-	v1 "github.com/ocurity/dracon/api/proto/v1"
+	v1 "github.com/smithy-security/smithy/api/proto/v1"
 
-	"github.com/ocurity/dracon/components/producers"
+	"github.com/smithy-security/smithy/components/producers"
 )
 
 func main() {
@@ -27,7 +27,7 @@ func main() {
 
 	issues := parseIssues(&results)
 
-	if err := producers.WriteDraconOut(
+	if err := producers.WriteSmithyOut(
 		"example-tool",
 		issues,
 	); err != nil {

docs/how-tos/components/example-producer/main_test.go

@@ -4,7 +4,7 @@ import (
 	"encoding/json"
 	"testing"
 
-	v1 "github.com/ocurity/dracon/api/proto/v1"
+	v1 "github.com/smithy-security/smithy/api/proto/v1"
 
 	"github.com/stretchr/testify/assert"
 	"github.com/stretchr/testify/require"

docs/how-tos/components/example-producer/task.yaml

@@ -4,7 +4,7 @@ kind: Task
 metadata:
   name: producer-example-tool
   labels:
-    v1.dracon.ocurity.com/component: producer
+    v1.smithy.smithy-security.com/component: producer
 spec:
   params:
   - name: producer-golang-example-tool
@@ -36,11 +36,11 @@ spec:
 
   - name: produce-issues
     imagePullPolicy: IfNotPresent
-    image: ghcr.io/ocurity/dracon/components/producers/example-tool/image:latest
+    image: ghcr.io/smithy-security/smithy/components/producers/example-tool/image:latest
     command: ["/app/components/producers/example-tool/example-tool-parser"]
     args:
     - "-in=/scratch/out.json"
-    - "-out=$(workspaces.output.path)/.dracon/producers/example-tool.pb"
+    - "-out=$(workspaces.output.path)/.smithy/producers/example-tool.pb"
     volumeMounts:
     - mountPath: /scratch
       name: scratch

docs/how-tos/components/writing-consumers.md

@@ -4,8 +4,8 @@ sidebar_position: 3
 
 # Consumers
 
-A consumer is a program that parses the Dracon compatible outputs and pushes
-them into arbitrary destinations. The Dracon compatible outputs from from
+A consumer is a program that parses the compatible outputs and pushes
+them into arbitrary destinations. The compatible outputs from
 *producers* and *enrichers*.
 
 ***
@@ -14,12 +14,12 @@ Consumers can be written in any language that supports protobufs. We currently
 have examples in Golang and Python. They are all structured in the same way:
 
 1. Parse program arguments:
-   1. `in`: the dracon compatible outputs location.
-   2. `raw`: whether or not to use enriched results.
-2. Parse all dracon compatible output files the `in` location.
+   1. `in`: the smithy-compatible outputs location.
+   2. `raw`: whether to use enriched results.
+2. Parse all output files the `in` location.
 3. Do arbitrary logic with issues.
 4. Create a Tekton Task `task.yaml` with
-   `.metadata.labels["v1.dracon.ocurity.com/component"] = consumer`.
+   `.metadata.labels["v1.smithy.smithy-security.com/component"] = consumer`.
 
 ## Consumer API
 

docs/how-tos/components/writing-producers.md

@@ -5,7 +5,7 @@ sidebar_position: 2
 # Producers
 
 A producer is a program that parses the output of a tool and converts it into
-Dracon compatible output that can be used by *enrichers* and *consumers*.
+Smithy compatible output that can be used by *enrichers* and *consumers*.
 
 ***
 
@@ -14,12 +14,12 @@ have examples in Golang and Python. They are all structured in the same way:
 
 1. Parse program arguments:
    1. `in`: the raw tool results file location.
-   2. `out`: where to place the Dracon compatible output file location.
+   2. `out`: where to place the Smithy compatible output file location.
 2. Parse the `in` file into Protobufs (`LaunchToolResponse`).
 3. Add metadata to Protobufs (e.g. git/source-code information).
 4. Write the protobuf bytes to the `out` file.
 5. Create a Tekton Task `task.yaml` with
-   `.metadata.labels["v1.dracon.ocurity.com/component"] = producer`.
+   `.metadata.labels["v1.smithy.smithy-security.com/component"] = producer`.
 
 ## Producer API
 

docs/how-tos/deploying-custom-components.md

@@ -1,18 +1,18 @@
-# Deploying your Custom Dracon Components
+# Deploying your Custom Smithy Components
 
 The first step is to build all the containers and push them to a registry
 that your cluster has access to. We use `make` to package our containers. For
 each component our Make will automatically generate a phony target with the
 path `components/{component type}/{component name}/docker`. We have a top-level
 target that creates all the component containers along with a couple of extra
-containers our system uses, such as draconctl.
+containers our system uses, such as smithyctl.
 
 The following examples are using the local container registry used by the KiND
 cluster, but make sure that you replace the URL with the registry URL that you
 are using, if you are using something else:
 
 ```bash
-make publish-component-containers CONTAINER_REPO=localhost:5000/ocurity/dracon
+make publish-component-containers CONTAINER_REPO=localhost:5000/smithy-security/smithy
 ```
 
 \* Notice that the repo we are using is slightly different than the
@@ -23,48 +23,48 @@ KiND cluster, that's not the case. Instead the registry's host is
 deploy the pipelines and their image repositories will also have to be set to
 this value.
 
-\*\*Make sure that you use the draconctl image that you pushed in the repository
+\*\*Make sure that you use the smithyctl image that you pushed in the repository
 
 You can package your components into a Helm package by running the following
 command:
 
 ```bash
-export CUSTOM_DRACON_VERSION=$(make print-DRACON_VERSION)
+export CUSTOM_SMITHY_VERSION=$(make print-SMITHY_VERSION)
 export CUSTOM_HELM_COMPONENT_PACKAGE_NAME=
-make cmd/draconctl/bin
-bin/cmd/draconctl components package \
-  --version ${CUSTOM_DRACON_VERSION} \
-  --chart-version ${CUSTOM_DRACON_VERSION} \
+make cmd/smithyctl/bin
+bin/cmd/smithyctl components package \
+  --version ${CUSTOM_SMITHY_VERSION} \
+  --chart-version ${CUSTOM_SMITHY_VERSION} \
   --name ${CUSTOM_HELM_COMPONENT_PACKAGE_NAME} \
   ./components
-helm upgrade ${CUSTOM_HELM_COMPONENT_PACKAGE_NAME} ./${CUSTOM_HELM_COMPONENT_PACKAGE_NAME}-${CUSTOM_DRACON_VERSION}.tgz \
+helm upgrade ${CUSTOM_HELM_COMPONENT_PACKAGE_NAME} ./${CUSTOM_HELM_COMPONENT_PACKAGE_NAME}-${CUSTOM_SMITHY_VERSION}.tgz \
   --install \
-  --namespace dracon
+  --namespace smithy
 ```
 
 If your custom components are local, you need to override the component registry
 you can do so with the following slightly modified helm command
 
 ```bash
-helm upgrade ${CUSTOM_HELM_COMPONENT_PACKAGE_NAME} ./${CUSTOM_HELM_COMPONENT_PACKAGE_NAME}-${CUSTOM_DRACON_VERSION}.tgz \
+helm upgrade ${CUSTOM_HELM_COMPONENT_PACKAGE_NAME} ./${CUSTOM_HELM_COMPONENT_PACKAGE_NAME}-${CUSTOM_SMITHY_VERSION}.tgz \
   --install \
-  --namespace dracon\
-  --set container_registry=kind-registry:5000/ocurity/dracon
+  --namespace smithy\
+  --set container_registry=kind-registry:5000/smithy-security/smithy
 ```
 
 After changes to your components you need to redeploy, you can do so as such:
 
 ```bash
 
-export CUSTOM_DRACON_VERSION=$(make print-DRACON_VERSION)
-make publish-component-containers CONTAINER_REPO=localhost:5000/ocurity/dracon
-bin/cmd/draconctl components package   --version ${CUSTOM_DRACON_VERSION}   \
-  --chart-version ${CUSTOM_DRACON_VERSION}   \
+export CUSTOM_SMITHY_VERSION=$(make print-SMITHY_VERSION)
+make publish-component-containers CONTAINER_REPO=localhost:5000/smithy-security/smithy
+bin/cmd/smithyctl components package   --version ${CUSTOM_SMITHY_VERSION}   \
+  --chart-version ${CUSTOM_SMITHY_VERSION}   \
   --name ${CUSTOM_HELM_COMPONENT_PACKAGE_NAME}   \
   ./components
 helm upgrade ${CUSTOM_HELM_COMPONENT_PACKAGE_NAME} \
-  ./${CUSTOM_HELM_COMPONENT_PACKAGE_NAME}-${CUSTOM_DRACON_VERSION}.tgz   \
+  ./${CUSTOM_HELM_COMPONENT_PACKAGE_NAME}-${CUSTOM_SMITHY_VERSION}.tgz   \
   --install \
-  --namespace dracon \
-  --set container_registry=kind-registry:5000/ocurity/dracon
+  --namespace smithy \
+  --set container_registry=kind-registry:5000/smithy-security/smithy
 ```

docs/how-tos/elasticsearch.md

@@ -1,19 +1,19 @@
 # Accessing the Kibana Dashboard
 
-Dracon ships with an instance of Elastic Search to store results in. We can use Kibana to explore it through a UI.
+Smithy ships with an instance of Elastic Search to store results in. We can use Kibana to explore it through a UI.
 
 ## Port-Forward the Kibana Pod
 
 ```bash
-kubectl -n dracon port-forward svc/dracon-kb-http 5601:5601
+kubectl -n smithy port-forward svc/smithy-kb-http 5601:5601
 ```
 
 ## Get the Credentials
 
 To log in to Kibana you need credentials. The username is `elastic`. You can retrieve the password by running:
 
 ```bash
-kubectl -n dracon get secret dracon-es-elastic-user \
+kubectl -n smithy get secret smithy-es-elastic-user \
     -o=jsonpath='{.data.elastic}' | \
     base64 -d &&\
     echo
@@ -23,15 +23,15 @@ kubectl -n dracon get secret dracon-es-elastic-user \
 
 And that's it! Now we can explore the Kibana Dashboard by navigating to http://localhost:5601/ in our browser and logging in with the credentials from above.
 
-To see any data that was created by Dracon we can use the `Discover` feature in Kibana. Click on `Analytics > Discover` on the homepage or [follow this link](http://localhost:5601/app/discover#).
+To see any data that was created by Smithy we can use the `Discover` feature in Kibana. Click on `Analytics > Discover` on the homepage or [follow this link](http://localhost:5601/app/discover#).
 
 ### Add a New Data View
 
 Then, we need to create a new data view. We only need to do this once.
 
 1. Click on the data dropdown, by default it will say something like `kibana_sample_data_...`
 2. Click on `Create a data view`
-   1. Name it `dracon`
+   1. Name it `smithy`
    2. Under `timestamp field` select `scan_start_time`
    3. Click `Create data view`
 

docs/reference/components/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Components",
+  "position": 4,
+  "link": {
+    "type": "generated-index",
+    "description": "Read about each component"
+
+  }
+}

docs/reference/components/consumers/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Consumers",
+  "position": 4,
+  "link": {
+    "type": "generated-index",
+    "description": "Components that consume and display your security alerts.\n\n"
+  }
+}

docs/reference/components/consumers/golang-gosec.md

@@ -0,0 +1 @@
+gosec

docs/reference/components/enrichers/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Enrichers",
+  "position": 3,
+  "link": {
+    "type": "generated-index",
+    "description": "Components that enrich your security alerts with more details and turn them into actionable events."
+  }
+}

docs/reference/components/enrichers/deduplication.md

@@ -0,0 +1 @@
+deduplication

docs/reference/components/producers/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Producers",
+  "position": 2,
+  "link": {
+    "type": "generated-index",
+    "description": "Components that scan your resources and produce security alerts."
+  }
+}

docs/reference/components/producers/golang-gosec.md

@@ -0,0 +1 @@
+gosec

docs/reference/components/sources/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Sources",
+  "position": 1,
+  "link": {
+    "type": "generated-index",
+    "description": "Components that fetch the resources which you need to scan."
+  }
+}