From d845b509b1ffcdce4396c28a0f735633e7037770 Mon Sep 17 00:00:00 2001 From: cspicer Date: Tue, 12 Oct 2021 19:31:14 -0400 Subject: [PATCH 1/5] Add a container hardening guide --- container-hardening.md | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 container-hardening.md diff --git a/container-hardening.md b/container-hardening.md new file mode 100644 index 0000000..a771028 --- /dev/null +++ b/container-hardening.md @@ -0,0 +1,33 @@ +# Container Hardening + +In general, container hardening is the proceess of utilizing container scanning tools to detect possible CVEs (Common Vulnerabilities & Exposures) and remediating them to minimize the attack surface of a container. Each individual, organization, or other entity may form their own requirements for this process and its outputs based on their needs and risk acceptance. Below is an example: + +> We are building a web server container using [Apache HTTP](https://httpd.apache.org/) version 2.4.48 as the server. Once built, we analyzed the container with a scanning tool (Anchore, Twistlock, Snyk, etc.) and detected [CVE-2021-39275](https://nvd.nist.gov/vuln/detail/CVE-2021-39275) was present. After reviewing the CVE, we decided to upgrade the Apache HTTP server to the newer version 2.4.51 in order to prevent the vulnerability from being exploited and remove the threat from the container. + +## SDP and Containter Hardening + +The hardening process undertaken for the containers of this repository is aligned with the [Iron Bank hardening process](https://repo1.dso.mil/dsop/dccscr/-/tree/master). This allows for containers offered by this repository to receive comparatively the same degree of hardening provided to containers being used across the United States Department of Defence (US DoD). Currently containers that have been hardened can be located in RepoOne [SDP repository](https://repo1.dso.mil/dsop/solutions-delivery-platform) and [Jenkinsfile-Runner repository](https://repo1.dso.mil/dsop/opensource/jenkins/jenkinsfile-runner). Additionally, the full breakdown of our hardening process is as follows, with the assumption that a given application has been containerized: + +1. Identify all dependencies required for the application and gather them in a tarball + 1. This includes any .jar, .rpm, .whl, or other packages/files needed for the application in the container to function + 2. Packaging dependencies in this manner allow for this step to be automated +2. Build and test the container for expected performance + 1. Upgrading or modifying components of a container may cause intended functionality of a given container to break, detecting this early helps reduce user impact +3. Create a release on Github hosting the dependency tarball + 1. Hosting the dependency tarball allows users to modify, build, and test containers in their own environments, including Iron Bank +4. Port updates to the Iron Bank repository for the respective container to use the new dependency tarball + 1. This includes creating a feature branch and updating the [hardening manifest](https://repo1.dso.mil/dsop/dccscr/-/tree/master/hardening%20manifest), Dockerfile, README, configuration or other supporting files +5. Run the updates through the Iron Bank container hardening pipeline + 1. This will typically be triggered automatically when changes are pushed to a given branch of the container repository, but can be triggered manually as well in the `CI/CD -> Pipelines` section of the repository +6. Review the scan results for offending CVE or compliance findings + 1. Can be located as an excel spreadsheet in the `csv-output` job artifact archive or displayed in the `check-cves` job of the pipeline +7. Remediate all possible findings, repeating steps 1 through 6 as necessary + 1. Each CVE can be searched for on the internet for their description and possible patchs or mitigations for their resolution, most notably via the [National Vulnerability Database](https://nvd.nist.gov/vuln/search) + 2. Each compliance finding will have their description and possible patch defined in the excel spreadsheet mentioned in step 6 + 3. The most common remediation techniques include, but are not limited to, updating packages to newer versions, removing packages, and applying system adminstration (ex. chmod a file to be used only by authorized users) to the container. +8. Submit justifications to the Iron Bank container hardening team for any non remediable CVE or compliance findings + 1. In the excel spreadsheet described in step 6, provide a written justification in the `justification` column for the correlating CVE row + 2. The Iron Bank provides guidance for creating justifications under the `Contributors` section [here](https://repo1.dso.mil/dsop/dccscr/-/tree/master) + 3. Select the `Issues` tab in the Iron Bank container repository, and append the justifications to the appropriate issue. + 4. Open a merge request via the `Merge requests` tab in the Iron Bank container repository to merge your feature branch to the development branch, and link the merge request to the corresponding issue. + 5. Iron Bank will provide a determination if further action is required \ No newline at end of file From 81583e6fd35648cab5d364f8ce3f6f820fea98b3 Mon Sep 17 00:00:00 2001 From: cspicer Date: Thu, 14 Oct 2021 22:51:45 -0400 Subject: [PATCH 2/5] detailed out container-hardening.md --- container-hardening.md | 95 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 78 insertions(+), 17 deletions(-) diff --git a/container-hardening.md b/container-hardening.md index a771028..2463248 100644 --- a/container-hardening.md +++ b/container-hardening.md @@ -1,33 +1,94 @@ # Container Hardening -In general, container hardening is the proceess of utilizing container scanning tools to detect possible CVEs (Common Vulnerabilities & Exposures) and remediating them to minimize the attack surface of a container. Each individual, organization, or other entity may form their own requirements for this process and its outputs based on their needs and risk acceptance. Below is an example: +In general, container hardening is the proceess of utilizing container +scanning tools to detect possible CVEs (Common Vulnerabilities & Exposures) +and remediating them to minimize the attack surface of a container. +Each individual, organization, or other entity may form their own requirements +for this process and its outputs based on their needs and risk acceptance. +Below is an example: -> We are building a web server container using [Apache HTTP](https://httpd.apache.org/) version 2.4.48 as the server. Once built, we analyzed the container with a scanning tool (Anchore, Twistlock, Snyk, etc.) and detected [CVE-2021-39275](https://nvd.nist.gov/vuln/detail/CVE-2021-39275) was present. After reviewing the CVE, we decided to upgrade the Apache HTTP server to the newer version 2.4.51 in order to prevent the vulnerability from being exploited and remove the threat from the container. +> We are building a web server container using [Apache HTTP](https://httpd.apache.org/) version 2.4.48 as the server. +> Once built, we analyzed the container with a scanning tool (Anchore, Twistlock, Snyk, etc.) +> and detected [CVE-2021-39275](https://nvd.nist.gov/vuln/detail/CVE-2021-39275) was present. +> After reviewing the CVE, we decided to upgrade the Apache HTTP server to the newer version 2.4.51 +> in order to prevent the vulnerability from being exploited and remove the threat from the container. -## SDP and Containter Hardening +## SDP and Container Hardening -The hardening process undertaken for the containers of this repository is aligned with the [Iron Bank hardening process](https://repo1.dso.mil/dsop/dccscr/-/tree/master). This allows for containers offered by this repository to receive comparatively the same degree of hardening provided to containers being used across the United States Department of Defence (US DoD). Currently containers that have been hardened can be located in RepoOne [SDP repository](https://repo1.dso.mil/dsop/solutions-delivery-platform) and [Jenkinsfile-Runner repository](https://repo1.dso.mil/dsop/opensource/jenkins/jenkinsfile-runner). Additionally, the full breakdown of our hardening process is as follows, with the assumption that a given application has been containerized: +The hardening process undertaken for the containers of this repository is +aligned with the [Iron Bank hardening process](https://repo1.dso.mil/dsop/dccscr/-/tree/master). +This allows for containers offered by this repository to receive comparatively +the same degree of hardening provided to containers being used across the +United States Department of Defence (US DoD). +Currently containers that have been hardened can be located in the +RepoOne [SDP repository](https://repo1.dso.mil/dsop/solutions-delivery-platform) and +[Jenkinsfile-Runner repository](https://repo1.dso.mil/dsop/opensource/jenkins/jenkinsfile-runner). +Additionally, the full breakdown of our hardening process is as follows, +with the assumption that a given application has been containerized: 1. Identify all dependencies required for the application and gather them in a tarball 1. This includes any .jar, .rpm, .whl, or other packages/files needed for the application in the container to function - 2. Packaging dependencies in this manner allow for this step to be automated + 2. Packaging dependencies in this manner allow for this step to be automated, + and will allow containers to be built in environments without network connection + 3. An example of a container following this pattern is Jenkins, examine the [prebuild](/jenkins/kubernetes/prebuild/) + folder for setting up scripts automating this process, + and the [Makefile](/jenkins/kubernetes/Makefile/) for stringing scripts together + > To use Make CLI functions in a terminal, type **make** + > followed by a subcommand from the Makefile. + > For example, to run the tarball creation automation, type **make build-dep**. + > At this time, creation of the tarball requires both the BAH-Public & BAH-Private keys. + > See a repository administator should you need to perform this action. 2. Build and test the container for expected performance - 1. Upgrading or modifying components of a container may cause intended functionality of a given container to break, detecting this early helps reduce user impact + 1. Upgrading or modifying components of a container may cause intended functionality + of a given container to break, detecting this early helps reduce user impact + 2. To build a container, follow your installed container tool's manual + > Using Docker for example, use **docker build --no-cache -t example-container:example-tag .** + 3. Testing the functionality of a container for expected behavior + is unique to each container and the applications they house. + Read any provided documentation for each application and how it should be deployed + 4. Each container should provide instruction for how to use or deploy it 3. Create a release on Github hosting the dependency tarball - 1. Hosting the dependency tarball allows users to modify, build, and test containers in their own environments, including Iron Bank + 1. Hosting the dependency tarball allows users to modify, build, and + test containers in their own environments, including Iron Bank + 2. For creating a release: + > - Create a tarball described in step 1 + > - Sign in to your GitHub account that has administrative privileges to the **SDP Images** repository + > - Navigate to the [releases section](https://github.com/boozallen/sdp-images/releases) + > - Select the **Draft a new release** button + > - Follow the DCAR naming convention shown on the releases page, upload the tarball, sha256, and sig files, and select **Publish release** 4. Port updates to the Iron Bank repository for the respective container to use the new dependency tarball - 1. This includes creating a feature branch and updating the [hardening manifest](https://repo1.dso.mil/dsop/dccscr/-/tree/master/hardening%20manifest), Dockerfile, README, configuration or other supporting files + 1. This includes creating a feature branch and updating the + [hardening manifest](https://repo1.dso.mil/dsop/dccscr/-/tree/master/hardening%20manifest), + Dockerfile, README, configuration or other supporting files + 2. You will need to [register](https://login.dso.mil/auth/realms/baby-yoda/protocol/openid-connect/registrations?client_id=account&response_type=code) + for an account if you don't have a Platform One account, + otherwise login to [repo one](https://repo1.dso.mil/) + 3. Request access to the respective repository by using the **Request Access** link + to the right of project ID underneath the name of the repository + at the top of the webpage if you don't have access to make changes 5. Run the updates through the Iron Bank container hardening pipeline - 1. This will typically be triggered automatically when changes are pushed to a given branch of the container repository, but can be triggered manually as well in the `CI/CD -> Pipelines` section of the repository + 1. This will typically be triggered automatically when changes are pushed to a + given branch of the container repository, but can be triggered manually as well + in the **CI/CD -> Pipelines** section of the repository 6. Review the scan results for offending CVE or compliance findings - 1. Can be located as an excel spreadsheet in the `csv-output` job artifact archive or displayed in the `check-cves` job of the pipeline + 1. Can be located as an excel spreadsheet in the **csv-output** job artifact + archive or displayed in the **check-cves** job of the pipeline 7. Remediate all possible findings, repeating steps 1 through 6 as necessary - 1. Each CVE can be searched for on the internet for their description and possible patchs or mitigations for their resolution, most notably via the [National Vulnerability Database](https://nvd.nist.gov/vuln/search) - 2. Each compliance finding will have their description and possible patch defined in the excel spreadsheet mentioned in step 6 - 3. The most common remediation techniques include, but are not limited to, updating packages to newer versions, removing packages, and applying system adminstration (ex. chmod a file to be used only by authorized users) to the container. + 1. Each CVE can be searched for on the internet for their description and + possible patchs or mitigations for their resolution, most notably + via the [National Vulnerability Database](https://nvd.nist.gov/vuln/search) + 2. Each compliance finding will have their description and possible patch + defined in the excel spreadsheet mentioned in step 6 + 3. The most common remediation techniques include, but are not limited to, + updating packages to newer versions, removing packages, and applying + system adminstration (ex. chmod a file to be used only by authorized users) to the container. 8. Submit justifications to the Iron Bank container hardening team for any non remediable CVE or compliance findings - 1. In the excel spreadsheet described in step 6, provide a written justification in the `justification` column for the correlating CVE row - 2. The Iron Bank provides guidance for creating justifications under the `Contributors` section [here](https://repo1.dso.mil/dsop/dccscr/-/tree/master) - 3. Select the `Issues` tab in the Iron Bank container repository, and append the justifications to the appropriate issue. - 4. Open a merge request via the `Merge requests` tab in the Iron Bank container repository to merge your feature branch to the development branch, and link the merge request to the corresponding issue. + 1. In the excel spreadsheet described in step 6, provide a written justification + in the `justification` column for the correlating CVE row + 2. The Iron Bank provides guidance for creating justifications under + the **Contributors** section [here](https://repo1.dso.mil/dsop/dccscr/-/tree/master) + 3. Select the **Issues** tab in the Iron Bank container repository, and append the justifications to the appropriate issue. + 4. Open a merge request via the **Merge requests** tab in the Iron Bank + container repository to merge your feature branch to the development branch, + and link the merge request to the corresponding issue. 5. Iron Bank will provide a determination if further action is required \ No newline at end of file From f67a74cb523943b1574d1626c14993c723c99d8e Mon Sep 17 00:00:00 2001 From: Peter Sigur Date: Tue, 16 Nov 2021 10:59:17 -0500 Subject: [PATCH 3/5] docs edits --- container-hardening.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/container-hardening.md b/container-hardening.md index 2463248..2d7d1d8 100644 --- a/container-hardening.md +++ b/container-hardening.md @@ -1,10 +1,10 @@ # Container Hardening -In general, container hardening is the proceess of utilizing container +In general, container hardening is the process of utilizing container scanning tools to detect possible CVEs (Common Vulnerabilities & Exposures) and remediating them to minimize the attack surface of a container. Each individual, organization, or other entity may form their own requirements -for this process and its outputs based on their needs and risk acceptance. +for this process and its outputs based on their needs and risk tolerance. Below is an example: > We are building a web server container using [Apache HTTP](https://httpd.apache.org/) version 2.4.48 as the server. @@ -13,15 +13,15 @@ Below is an example: > After reviewing the CVE, we decided to upgrade the Apache HTTP server to the newer version 2.4.51 > in order to prevent the vulnerability from being exploited and remove the threat from the container. -## SDP and Container Hardening +## Solutions Delivery Platform (SDP) and Container Hardening The hardening process undertaken for the containers of this repository is aligned with the [Iron Bank hardening process](https://repo1.dso.mil/dsop/dccscr/-/tree/master). This allows for containers offered by this repository to receive comparatively the same degree of hardening provided to containers being used across the -United States Department of Defence (US DoD). +United States Department of Defense (US DoD). Currently containers that have been hardened can be located in the -RepoOne [SDP repository](https://repo1.dso.mil/dsop/solutions-delivery-platform) and +Repo One [SDP repository](https://repo1.dso.mil/dsop/solutions-delivery-platform) and [Jenkinsfile-Runner repository](https://repo1.dso.mil/dsop/opensource/jenkins/jenkinsfile-runner). Additionally, the full breakdown of our hardening process is as follows, with the assumption that a given application has been containerized: @@ -37,7 +37,7 @@ with the assumption that a given application has been containerized: > followed by a subcommand from the Makefile. > For example, to run the tarball creation automation, type **make build-dep**. > At this time, creation of the tarball requires both the BAH-Public & BAH-Private keys. - > See a repository administator should you need to perform this action. + > See a repository administrator should you need to perform this action. 2. Build and test the container for expected performance 1. Upgrading or modifying components of a container may cause intended functionality of a given container to break, detecting this early helps reduce user impact @@ -75,20 +75,20 @@ with the assumption that a given application has been containerized: archive or displayed in the **check-cves** job of the pipeline 7. Remediate all possible findings, repeating steps 1 through 6 as necessary 1. Each CVE can be searched for on the internet for their description and - possible patchs or mitigations for their resolution, most notably + possible patches or mitigation steps for their resolution, most notably via the [National Vulnerability Database](https://nvd.nist.gov/vuln/search) 2. Each compliance finding will have their description and possible patch - defined in the excel spreadsheet mentioned in step 6 + defined in the Excel spreadsheet mentioned in step 6 3. The most common remediation techniques include, but are not limited to, updating packages to newer versions, removing packages, and applying system adminstration (ex. chmod a file to be used only by authorized users) to the container. 8. Submit justifications to the Iron Bank container hardening team for any non remediable CVE or compliance findings - 1. In the excel spreadsheet described in step 6, provide a written justification + 1. In the Excel spreadsheet described in step 6, provide a written justification in the `justification` column for the correlating CVE row - 2. The Iron Bank provides guidance for creating justifications under + 2. The Iron Bank provides guidance for creating justifications under the **Contributors** section [here](https://repo1.dso.mil/dsop/dccscr/-/tree/master) - 3. Select the **Issues** tab in the Iron Bank container repository, and append the justifications to the appropriate issue. + 3. Select the **Issues** tab in the Iron Bank container repository, and append the justifications to the appropriate issue 4. Open a merge request via the **Merge requests** tab in the Iron Bank container repository to merge your feature branch to the development branch, - and link the merge request to the corresponding issue. + and link the merge request to the corresponding issue 5. Iron Bank will provide a determination if further action is required \ No newline at end of file From 42216f48dd4dfa3509c029061657caa1bb1e76e7 Mon Sep 17 00:00:00 2001 From: Peter Sigur Date: Tue, 16 Nov 2021 11:05:38 -0500 Subject: [PATCH 4/5] more docs edits --- container-hardening.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/container-hardening.md b/container-hardening.md index 2d7d1d8..ce97b29 100644 --- a/container-hardening.md +++ b/container-hardening.md @@ -28,26 +28,26 @@ with the assumption that a given application has been containerized: 1. Identify all dependencies required for the application and gather them in a tarball 1. This includes any .jar, .rpm, .whl, or other packages/files needed for the application in the container to function - 2. Packaging dependencies in this manner allow for this step to be automated, - and will allow containers to be built in environments without network connection + 2. Packaging dependencies in this manner allows for this step to be automated, + and will allow containers to be built in environments without external network connections 3. An example of a container following this pattern is Jenkins, examine the [prebuild](/jenkins/kubernetes/prebuild/) folder for setting up scripts automating this process, and the [Makefile](/jenkins/kubernetes/Makefile/) for stringing scripts together - > To use Make CLI functions in a terminal, type **make** - > followed by a subcommand from the Makefile. - > For example, to run the tarball creation automation, type **make build-dep**. - > At this time, creation of the tarball requires both the BAH-Public & BAH-Private keys. + > To use Make CLI functions in a terminal, type `make` + > followed by a subcommand from the Makefile. + > For example, to run the tarball creation automation, type `make build-dep`. + > At this time, creation of the tarball requires both the BAH-Public & BAH-Private keys. > See a repository administrator should you need to perform this action. 2. Build and test the container for expected performance 1. Upgrading or modifying components of a container may cause intended functionality of a given container to break, detecting this early helps reduce user impact 2. To build a container, follow your installed container tool's manual - > Using Docker for example, use **docker build --no-cache -t example-container:example-tag .** + > Using Docker for example, use `docker build --no-cache -t example-container:example-tag .` 3. Testing the functionality of a container for expected behavior is unique to each container and the applications they house. Read any provided documentation for each application and how it should be deployed 4. Each container should provide instruction for how to use or deploy it -3. Create a release on Github hosting the dependency tarball +3. Create a release on GitHub hosting the dependency tarball 1. Hosting the dependency tarball allows users to modify, build, and test containers in their own environments, including Iron Bank 2. For creating a release: @@ -62,7 +62,7 @@ with the assumption that a given application has been containerized: Dockerfile, README, configuration or other supporting files 2. You will need to [register](https://login.dso.mil/auth/realms/baby-yoda/protocol/openid-connect/registrations?client_id=account&response_type=code) for an account if you don't have a Platform One account, - otherwise login to [repo one](https://repo1.dso.mil/) + otherwise login to [Repo One](https://repo1.dso.mil/) 3. Request access to the respective repository by using the **Request Access** link to the right of project ID underneath the name of the repository at the top of the webpage if you don't have access to make changes @@ -71,7 +71,7 @@ with the assumption that a given application has been containerized: given branch of the container repository, but can be triggered manually as well in the **CI/CD -> Pipelines** section of the repository 6. Review the scan results for offending CVE or compliance findings - 1. Can be located as an excel spreadsheet in the **csv-output** job artifact + 1. Can be located as an Excel spreadsheet in the **csv-output** job artifact archive or displayed in the **check-cves** job of the pipeline 7. Remediate all possible findings, repeating steps 1 through 6 as necessary 1. Each CVE can be searched for on the internet for their description and From a7cf30d55c19704a2570dc477a134192544f0770 Mon Sep 17 00:00:00 2001 From: Peter Sigur Date: Wed, 17 Nov 2021 10:22:20 -0500 Subject: [PATCH 5/5] additional tweaks, adding link to primary README --- container-hardening.md | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/container-hardening.md b/container-hardening.md index ce97b29..76712dc 100644 --- a/container-hardening.md +++ b/container-hardening.md @@ -1,6 +1,6 @@ -# Container Hardening +# Container Hardening Guide -In general, container hardening is the process of utilizing container +Container hardening is the process of utilizing container scanning tools to detect possible CVEs (Common Vulnerabilities & Exposures) and remediating them to minimize the attack surface of a container. Each individual, organization, or other entity may form their own requirements @@ -13,14 +13,16 @@ Below is an example: > After reviewing the CVE, we decided to upgrade the Apache HTTP server to the newer version 2.4.51 > in order to prevent the vulnerability from being exploited and remove the threat from the container. +*Note: repository layout information and common container commands are available in the [SDP-Images README](./README.rst)* + ## Solutions Delivery Platform (SDP) and Container Hardening The hardening process undertaken for the containers of this repository is -aligned with the [Iron Bank hardening process](https://repo1.dso.mil/dsop/dccscr/-/tree/master). +aligned to the [Iron Bank hardening process](https://repo1.dso.mil/dsop/dccscr/-/tree/master). This allows for containers offered by this repository to receive comparatively the same degree of hardening provided to containers being used across the United States Department of Defense (US DoD). -Currently containers that have been hardened can be located in the +Containers that have been fully hardened can be found in the Repo One [SDP repository](https://repo1.dso.mil/dsop/solutions-delivery-platform) and [Jenkinsfile-Runner repository](https://repo1.dso.mil/dsop/opensource/jenkins/jenkinsfile-runner). Additionally, the full breakdown of our hardening process is as follows, @@ -32,7 +34,7 @@ with the assumption that a given application has been containerized: and will allow containers to be built in environments without external network connections 3. An example of a container following this pattern is Jenkins, examine the [prebuild](/jenkins/kubernetes/prebuild/) folder for setting up scripts automating this process, - and the [Makefile](/jenkins/kubernetes/Makefile/) for stringing scripts together + and the [Makefile](/jenkins/kubernetes/Makefile) for stringing scripts together > To use Make CLI functions in a terminal, type `make` > followed by a subcommand from the Makefile. > For example, to run the tarball creation automation, type `make build-dep`. @@ -43,14 +45,14 @@ with the assumption that a given application has been containerized: of a given container to break, detecting this early helps reduce user impact 2. To build a container, follow your installed container tool's manual > Using Docker for example, use `docker build --no-cache -t example-container:example-tag .` - 3. Testing the functionality of a container for expected behavior - is unique to each container and the applications they house. - Read any provided documentation for each application and how it should be deployed - 4. Each container should provide instruction for how to use or deploy it + 3. Testing the functionality of a container for expected behavior + is unique to each container and the applications they house - + read any provided documentation for each application and how it should be deployed + 4. Each container should provide instructions for how to use or deploy it 3. Create a release on GitHub hosting the dependency tarball 1. Hosting the dependency tarball allows users to modify, build, and test containers in their own environments, including Iron Bank - 2. For creating a release: + 2. To create a release: > - Create a tarball described in step 1 > - Sign in to your GitHub account that has administrative privileges to the **SDP Images** repository > - Navigate to the [releases section](https://github.com/boozallen/sdp-images/releases) @@ -60,9 +62,9 @@ with the assumption that a given application has been containerized: 1. This includes creating a feature branch and updating the [hardening manifest](https://repo1.dso.mil/dsop/dccscr/-/tree/master/hardening%20manifest), Dockerfile, README, configuration or other supporting files - 2. You will need to [register](https://login.dso.mil/auth/realms/baby-yoda/protocol/openid-connect/registrations?client_id=account&response_type=code) - for an account if you don't have a Platform One account, - otherwise login to [Repo One](https://repo1.dso.mil/) + 2. Login to [Repo One](https://repo1.dso.mil/) + (you will need to [register](https://login.dso.mil/auth/realms/baby-yoda/protocol/openid-connect/registrations?client_id=account&response_type=code) + if you don't already have a Platform One account) 3. Request access to the respective repository by using the **Request Access** link to the right of project ID underneath the name of the repository at the top of the webpage if you don't have access to make changes @@ -79,9 +81,9 @@ with the assumption that a given application has been containerized: via the [National Vulnerability Database](https://nvd.nist.gov/vuln/search) 2. Each compliance finding will have their description and possible patch defined in the Excel spreadsheet mentioned in step 6 - 3. The most common remediation techniques include, but are not limited to, + 3. The most common remediation techniques include, but are not limited to: updating packages to newer versions, removing packages, and applying - system adminstration (ex. chmod a file to be used only by authorized users) to the container. + system adminstration (ex. chmod a file to be used only by authorized users) to the container 8. Submit justifications to the Iron Bank container hardening team for any non remediable CVE or compliance findings 1. In the Excel spreadsheet described in step 6, provide a written justification in the `justification` column for the correlating CVE row