[OSDOCS#17176]: Make changes as per the errors and warnings CQA Remediation-1

modules/security-build-designing.adoc

@@ -6,29 +6,20 @@
 [id="security-build-designing_{context}"]
 = Designing your build process
 
+[role="_abstract"]
+You can design your container image management to separate control across teams by using layered images, integrate automated security testing into your CI process, and sign custom containers to ensure integrity between build and deployment.
+
 You can design your container image management and build process to use container layers so that you can separate control.
 
 image::build_process2.png["Designing Your Build Process", align="center"]
 
-For example, an operations team manages base images, while architects manage
-middleware, runtimes, databases, and other solutions. Developers can then focus
-on application layers and focus on writing code.
+For example, an operations team manages base images, while architects manage middleware, runtimes, databases, and other solutions. Developers can then focus on application layers and focus on writing code.
 
-Because new vulnerabilities are identified daily, you need to proactively check
-container content over time. To do this, you should integrate automated security
-testing into your build or CI process. For example: 
+Because new vulnerabilities are identified daily, you need to proactively check container content over time. To do this, you should integrate automated security testing into your build or CI process. For example: 
 
-* SAST / DAST – Static and Dynamic security testing tools.
-* Scanners for real-time checking against known vulnerabilities. Tools like these
-catalog the open source packages in your container, notify you of any known 
-vulnerabilities, and update you when new vulnerabilities are discovered in
-previously scanned packages.
+* SAST / DAST - Static and Dynamic security testing tools.
+* Scanners for real-time checking against known vulnerabilities. Tools such as these catalog the open source packages in your container, notify you of any known vulnerabilities, and update you when new vulnerabilities are discovered in previously scanned packages.
 
-Your CI process should include policies that flag builds with issues discovered
-by security scans so that your team can take appropriate action to address those
-issues. You should sign your custom built containers to ensure that nothing is
-tampered with between build and deployment.
+Your CI process should include policies that flag builds with issues discovered by security scans so that your team can take appropriate action to address those issues. You should sign your custom built containers to ensure that nothing is tampered with between build and deployment.
 
-Using GitOps methodology, you can use the same CI/CD mechanisms to
-manage not only your application configurations, but also your
-{product-title} infrastructure.
+Using GitOps methodology, you can use the same CI/CD mechanisms to manage not only your application configurations, but also your {product-title} infrastructure.

modules/security-build-inputs.adoc

@@ -6,10 +6,12 @@
 [id="security-build-inputs_{context}"]
 =  Securing inputs during builds
 
+[role="_abstract"]
+You can protect sensitive credentials required during builds by defining input secrets that give access to dependent resources without exposing those credentials in the final application image.
+
 In some scenarios, build operations require credentials to access dependent resources, but it is undesirable for those credentials to be available in the final application image produced by the build. You can define input secrets for this purpose.
 
-For example, when building a Node.js application, you can set up your private mirror for Node.js modules. To download modules from that private mirror, you must supply a custom `.npmrc` file for the build that contains
-a URL, user name, and password. For security reasons, you do not want to expose your credentials in the application image.
+For example, when building a Node.js application, you can set up your private mirror for Node.js modules. To download modules from that private mirror, you must supply a custom `.npmrc` file for the build that has a URL, user name, and password. For security reasons, you do not want to expose your credentials in the application image.
 
 Using this example scenario, you can add an input secret to a new `BuildConfig` object.
 
@@ -22,7 +24,7 @@ Using this example scenario, you can add an input secret to a new `BuildConfig`
 $ oc create secret generic secret-npmrc --from-file=.npmrc=~/.npmrc
 ----
 +
-This creates a new secret named `secret-npmrc`, which contains the base64 encoded content of the `~/.npmrc` file.
+This creates a new secret named `secret-npmrc`, which has the base64 encoded content of the `~/.npmrc` file.
 
 . Add the secret to the `source` section in the existing `BuildConfig` object:
 +

modules/security-build-knative.adoc

@@ -6,7 +6,8 @@
 [id="security-build-knative_{context}"]
 = Building Knative serverless applications
 
-Relying on Kubernetes and Kourier, you can build, deploy, and manage serverless applications by using OpenShift Serverless in {product-title}.
+[role="_abstract"]
+You can build, deploy, and manage serverless applications by using OpenShift Serverless in {product-title}, relying on Kubernetes and Kourier,  leveraging S2I builder images and Knative services for scalable, event-driven workloads.
 
 As with other builds, you can use S2I images to build your containers, then serve them using Knative services. View Knative application builds through the
 *Topology* view of the {product-title} web console.

modules/security-build-management.adoc

@@ -6,30 +6,19 @@
 [id="security-build-management_{context}"]
 = Managing builds
 
-You can use Source-to-Image (S2I) to combine source code and base images.
-_Builder images_ make use of S2I to enable your development and operations teams
-to collaborate on a reproducible build environment.
-With Red Hat S2I images available as Universal Base Image (UBI) images,
-you can now freely redistribute your software with
-base images built from real {op-system-base} RPM packages.
-Red Hat has removed subscription restrictions to allow this.
-
-When developers commit code with Git for an application using build images,
-{product-title} can perform the following functions:
-
-* Trigger, either by using webhooks on the code repository or other automated
-continuous integration (CI) process, to automatically assemble a new image from
-available artifacts, the S2I builder image, and the newly committed code.
+[role="_abstract"]
+You can use Source-to-Image (S2I) builder images that enable development and operations teams to collaborate on reproducible builds, using Red Hat Universal Base Images that you can freely redistribute with your applications.
+
+You can use Source-to-Image (S2I) to combine source code and base images. _Builder images_ make use of S2I to enable your development and operations teams to collaborate on a reproducible build environment. With Red Hat S2I images available as Universal Base Image (UBI) images, you can now freely redistribute your software with base images built from real {op-system-base} RPM packages. Red Hat has removed subscription restrictions to allow this.
+
+When developers commit code with Git for an application by using build images, {product-title} can perform the following functions:
+
+* Trigger, either by using webhooks on the code repository or other automated continuous integration (CI) process, to automatically assemble a new image from available artifacts, the S2I builder image, and the newly committed code.
 * Automatically deploy the newly built image for testing. 
-* Promote the tested image to production where it can be automatically deployed
-using a CI process.
+* Promote the tested image to production where it can be automatically deployed using a CI process.
 
 image::build_process1.png["Source-to-Image Builds", align="center"]
 
-You can use the integrated OpenShift Container Registry to manage access to final images.
-Both S2I and native build images are automatically pushed to your OpenShift Container
-Registry.
+You can use the integrated OpenShift Container Registry to manage access to final images. Both S2I and native build images are automatically pushed to your OpenShift Container Registry.
 
-In addition to the included Jenkins for CI, you can also integrate your own
-build and CI environment with {product-title} using RESTful APIs, as well as use
-any API-compliant image registry.
+In addition to the included Jenkins for CI, you can also integrate your own build and CI environment with {product-title} using RESTful APIs, and use any API-compliant image registry.

modules/security-build-once.adoc

@@ -6,26 +6,26 @@
 [id="security-build-once_{context}"]
 = Building once, deploying everywhere
 
-Using {product-title} as the standard platform for container builds enables you
-to guarantee the security of the build environment. Adhering to a "build once,
-deploy everywhere" philosophy ensures that the product of the build process is
-exactly what is deployed in production.
+[role="_abstract"]
+You can build container images once in a secure environment and deploy them unchanged across all stages. Using {product-title} as your build standard guarantees this security, ensuring production deployments match verified builds and preventing runtime vulnerabilities.
 
-It is also important to maintain the immutability of your containers. You should
-not patch running containers, but rebuild and redeploy them.
+It is also important to maintain the immutability of your containers. You should not patch running containers, but rebuild and redeploy them.
 
-As your software moves through the stages of building, testing, and production, it is
-important that the tools making up your software supply chain be trusted. The
-following figure illustrates the process and tools that could be incorporated
-into a trusted software supply chain for containerized software:
+As your software moves through the stages of building, testing, and production, it is important that the tools making up your software supply chain be trusted. The following figure illustrates the process and tools that could be incorporated into a trusted software supply chain for containerized software:
 
 image::trustedsupplychain.png["", align="center"]
 
-{product-title} can be integrated with trusted code repositories (such as GitHub)
-and development platforms (such as Che) for creating and managing secure code.
-Unit testing could rely on  
-link:https://cucumber.io/[Cucumber] and link:https://junit.org/[JUnit].
+{product-title} can be integrated with trusted code repositories (such as GitHub) and development platforms (such as Che) for creating and managing secure code. Unit testing frameworks can validate code quality before builds.
 
-You can inspect your containers for vulnerabilities and configuration issues at build, deploy, or runtime with https://www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes[Red Hat Advanced Cluster Security for Kubernetes]. For images stored in Quay, you can use the https://access.redhat.com/products/red-hat-quay[Clair scanner] to inspect images at rest. In addition, there are https://catalog.redhat.com/software/vulnerability-scanner/search[certified vulnerability scanners] available in the Red Hat ecosystem catalog.
+You can inspect your containers for vulnerabilities and configuration issues at build, deploy, or runtime with Red Hat Advanced Cluster Security for Kubernetes. For images stored in Quay, you can use the Clair scanner to inspect images at rest. In addition, certified vulnerability scanners are available in the Red Hat ecosystem catalog.
 
-Tools such as link:https://sysdig.com[Sysdig] can provide ongoing monitoring of your containerized applications.
+Monitoring tools can provide ongoing visibility of your containerized applications.
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://cucumber.io/[Cucumber]
+* link:https://junit.org/[JUnit]
+* link:https://www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes[Red Hat Advanced Cluster Security for Kubernetes]
+* link:https://access.redhat.com/products/red-hat-quay[Clair scanner]
+* link:https://catalog.redhat.com/software/vulnerability-scanner/search[Certified vulnerability scanners]
+* link:https://sysdig.com[Sysdig]

modules/security-deploy-continuous.adoc

@@ -6,6 +6,5 @@
 [id="security-deploy-continuous_{context}"]
 = Automating continuous deployment
 
-You can integrate your own continuous deployment (CD) tooling with {product-title}.
-
-By leveraging CI/CD and {product-title}, you can automate the process of rebuilding the application to incorporate the latest fixes, testing, and ensuring that it is deployed everywhere within the environment.
+[role="_abstract"]
+You can integrate your own continuous deployment (CD) tool with {product-title}. By leveraging continuous integration and continuous deployment (CI/CD) and {product-title}, you can automate the process of rebuilding the application to incorporate the latest fixes, testing, and ensuring that it is deployed everywhere within the environment.

modules/security-deploy-image-sources.adoc

@@ -6,23 +6,13 @@
 [id="security-deploy-image-sources_{context}"]
 = Controlling what image sources can be deployed
 
-It is important that the intended images are actually being deployed, that the
-images including the contained content
-are from trusted sources, and they have not been altered. Cryptographic signing
-provides this assurance. {product-title} enables cluster administrators to apply
-security policy that is broad or narrow, reflecting deployment environment and
-security requirements. Two parameters define this policy:
+[role="_abstract"]
+It is important that the intended images are actually being deployed, that the images including the contained content are from trusted sources, and they have not been altered. Cryptographic signing provides this assurance. {product-title} enables cluster administrators to apply security policy that is broad or narrow, reflecting deployment environment and security requirements. Two parameters define this policy:
 
 * one or more registries, with optional project namespace
 * trust type, such as accept, reject, or require public key(s)
 
-You can use these policy parameters to allow, deny, or require a trust
-relationship for entire registries, parts of registries, or individual
-images. Using trusted public keys, you can ensure that the source is
-cryptographically verified.
-The policy rules apply to nodes. Policy may be
-applied uniformly across all nodes or targeted for different node workloads (for
-example, build, zone, or environment).
+You can use these policy parameters to allow, deny, or require a trust relationship for entire registries, parts of registries, or individual images. Using trusted public keys, you can ensure that the source is cryptographically verified. The policy rules apply to nodes. Policy might be applied uniformly across all nodes or targeted for different node workloads (for example, build, zone, or environment).
 
 .Example image signature policy file
 [source,json]
@@ -60,10 +50,7 @@ example, build, zone, or environment).
 }
 ----
 
-The policy can be saved onto a node as `/etc/containers/policy.json`.
-Saving this file to a node is best accomplished using a new
-`MachineConfig` object. This
-example enforces the following rules:
+The policy can be saved onto a node as `/etc/containers/policy.json`. Saving this file to a node is best accomplished using a new `MachineConfig` object. This example enforces the following rules:
 
 * Require images from the Red Hat Registry (`registry.access.redhat.com`) to be
 signed by the Red Hat public key.

modules/security-deploy-secrets.adoc

@@ -6,29 +6,19 @@
 [id="security-deploy-secrets_{context}"]
 = Creating secrets and config maps
 
-The `Secret` object type provides a mechanism to hold sensitive information such
-as passwords, {product-title} client configuration files, `dockercfg` files,
-and private source repository credentials. Secrets decouple sensitive content
-from pods. You can mount secrets into containers using a volume plugin or the
-system can use secrets to perform actions on behalf of a pod.
+[role="_abstract"]
+The `Secret` object type provides a mechanism to hold sensitive information such as passwords, {product-title} client configuration files, `dockercfg` files, and private source repository credentials. Secrets decouple sensitive content from pods. You can mount secrets into containers by using a volume plugin or the system can use secrets to perform actions on behalf of a pod.
 
-For example, to add a secret to your deployment configuration
-so that it can access a private image repository, do the following:
+Config maps are similar to secrets, but are designed to support working with strings that do not contain sensitive information. The `ConfigMap` object holds key-value pairs of configuration data that can be consumed in pods or used to store configuration data for system components such as controllers.
+
+For example, to add a secret to your deployment so that it can access a private image repository, do the following:
 
 .Procedure
 
 . Log in to the {product-title} web console.
 
 . Create a new project.
 
-. Navigate to *Resources* -> *Secrets* and create a new secret. Set `Secret Type` to
-`Image Secret` and `Authentication Type` to `Image Registry Credentials` to
-enter credentials for accessing a private image repository.
-
-. When creating a deployment configuration (for example, from the *Add to Project* ->
-*Deploy Image* page), set the `Pull Secret` to your new secret.
+. Navigate to *Resources* -> *Secrets* and create a new secret. Set `Secret Type` to `Image Secret` and `Authentication Type` to `Image Registry Credentials` to enter credentials for accessing a private image repository.
 
-Config maps are similar to secrets, but are designed to support working with
-strings that do not contain sensitive information. The `ConfigMap` object holds
-key-value pairs of configuration data that can be consumed in pods or used to
-store configuration data for system components such as controllers.
+. When creating a deployment (for example, from the *Add to Project* -> *Deploy Image* page), set the `Pull Secret` to your new secret.