vania-janet/multiturn-rag-retrieval-data huggingface dataset:
This command returns either cc, cd, ci, or pr, depending on which pipeline is running. This way, you can reuse the setup script between pipelines if necessary.





 Static code scan 

The static code scan stage runs a static code analyzer tool on the specified app repo codebases.

CC pipeline provides the repos that are found in the inventory for the scanner.

You can use any of the following methods to add static code to your pipeline:



* Provide an already running SonarQube instance name, URL, and credentials by adding the SonarQube tool to your toolchain. The static-scan task runs a scan on the specified repos.
* Add your code to the static-scan custom stage in your .pipeline-config.yaml file for a custom implementation.







 Dynamic scan 

The Dynamic scan stage runs a dynamic application security testing tool to find vulnerabilities in the deployed application.



* Add your own dynamic scan code to the dynamic-scan custom stage in your .pipeline-config.yaml file for a custom implementation.



To learn more about configuring dynamic scan by using OWASP-ZAP, see [Configuring ZAP scan for CC pipeline](https://cloud.ibm.com/docs/devsecops?topic=devsecops-zap-scanszap-scan-for-cc).





 Scans and checks in compliance checks 



Table 3. Compliance scans and checks

 Scan or check Description 

 Detect secrets The [IBM Detect Secrets](https://github.com/IBM/detect-secrets) tool identifies where secrets are visible in app code. 
 Code Risk Analyzer vulnerability scan Finds vulnerabilities for all of the app package dependencies, container base images, and operating system packages. Uses the Code Risk Analyzer tool. 
 Code Risk Analyzer CIS check Runs configuration checks on Kubernetes deployment manifests. Uses the Code Risk Analyzer tool. 
 Code Risk Analyzer Bill of Material (BOM) check The BOM for a specified repo that captures the pedigree of all of the dependencies. This BOM is collected at different granularities.
IBM Cloud Controller Manager v1.21.14-10 v1.21.14-12 Ignored Nancy dependency check failure. 
 IBM Cloud File Storage for Classic plug-in and monitor 425 427 Updated universal base image (UBI) to resolve CVEs. 
 Key Management Service provider v2.5.13 v2.6.3 Updated Go dependencies and to Go version 1.19.6. 
 Load balancer and Load balancer monitor for IBM Cloud Provider 2325 2383 Updated to armada-utils version 1.9.35. 
 OpenVPN client 2.5.6-r1-IKS-648 2.5.8-r0-IKS-674-amd64 Remediate [CVE-2023-0286](https://nvd.nist.gov/vuln/detail/CVE-2023-0286), [CVE-2022-4304](https://nvd.nist.gov/vuln/detail/CVE-2022-4304), [CVE-2022-4450](https://nvd.nist.gov/vuln/detail/CVE-2022-4450), [CVE-2023-0215](https://nvd.nist.gov/vuln/detail/CVE-2023-0215). 
 OpenVPN server 2.5.6-r1-IKS-647 2.5.8-r0-IKS-673-amd64 Remediate [CVE-2023-0286](https://nvd.nist.gov/vuln/detail/CVE-2023-0286), [CVE-2022-4304](https://nvd.nist.gov/vuln/detail/CVE-2022-4304), [CVE-2022-4450](https://nvd.nist.gov/vuln/detail/CVE-2022-4450), [CVE-2023-0215](https://nvd.nist.gov/vuln/detail/CVE-2023-0215).
Importing an encrypted image by using the IBM Cloud API 

You can use the SoftLayer API to import an encrypted image from IBM Cloud® Object Storage and create an image template. When your image template is created, you can use it to provision instances.

To limit access to only the information that is needed to complete the import task, authenticate with a service ID. The service ID needs access to only the encrypted image in IBM Cloud Object Storage that you want to import and the Key Protect instance where your root key is stored.

The following python snippet shows an example of how you can access the [SoftLayer_Virtual_Guest_Block_Device_Template_Group ![External link icon](https://cloud.ibm.com/docs-content/v1/content/icons/launch-glyph.svg)](https://sldn.softlayer.com/reference/services/SoftLayer_Virtual_Guest_Block_Device_Template_Group/) API and use the createFromIcos method to create an image template.

import SoftLayer

client = SoftLayer.create_client_from_env(username='<user>',
api_key='<api_key>',
endpoint_url='https://api.softlayer.com/rest/v3',
timeout=240)
group_svc = client['Virtual_Guest_Block_Device_Template_Group']
config = {'name':'my_encrypted_image',
'note':'my note',
'operatingSystemReferenceCode':'REDHAT_7_64',
'uri':'cos://<region_name>/<bucket_name>/xx123.Rhel_7_encrypted.raw',
'bootMode':'my boot mode',
'cloud-init': True,
'byol': True,
'encrypted': True,
'ibmApiKey':'<api_key>',
Code Risk Analyzer (CRA) detects multiple types of vulnerabilities, like app dependency and image vulnerability.

The type of vulnerability can be of the following: nameos, python, js, golang, or java.

If the type of vulnerability is of type os, an os-vulnerability label is attached to the issue. For any other type of vulnerability, an app-vulnerability label is attached to the issue.





 Labels for incident issues with available fixes 

For incident issues that are created by the continuous integration (CI) pipeline or continuous compliance (CC) pipeline, the scanner might have remediation information as a part of the scan result. If remediation information is available, a fix-available label is added to the incident issue with a link to the fix description inside the issue description.

The absence of the fix-available label does not mean that the issue is not actionable because not every scanner includes the fix information in the scan result. The scanner suggests the fix information, and that information comes from wherever the scanner sources this "fix" data. Some scanners might not have up-to-date "fix" dictionaries or do not contain information for a fix.







 Incident issues with due date 

When you use the [collect-evidence](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-collect-evidence) script, incident issues are created and attached to the collected evidence. If issues are found in production, they can have a specified time period in which they must be fixed so that deployments are not blocked. The time frame that is given to fix the problem in production is called the grace period. However, for better readability, Due Date is now available in incident issues so that users know the date when the fix is due without calculating it from the grace period.

If an issue such as vulnerability or CVE is found in production, and the same problem is also found in a build, the build does not make the situation worse. The feature can be deployed, and the team can focus on fixing the issue in production.





 Configuring custom grace periods on the CC pipeline 

The Continuous Compliance (CC) pipeline calculates the due dates of incident issues based on the severity of an issue.
This command checks the connectivity-configuration posture of a Kubernetes application against the [NIST SP 800-53 SC-7(5) control](https://csrc.nist.gov/projects/cprt/catalog/cprt/framework/version/SP_800_53_5_1_0/home?element=SC-7). It verifies that the connectivity of every workload is controlled by at least one NetworkPolicy resource, and that nonsecure ports are blocked for both ingress and egress.

The netpol-analyze command can also provide a connectivity report for the scanned application, showing all of the allowed connections between the application workloads. You can use this report as evidence for compliance, or to help debug connectivity issues. You can also use this command to provide lint results for the scanned network policies and then use these results to improve network-policy efficiency and readability. In some cases, lint results might also point to an error in the network policy definitions.



 NetworkPolicy analysis command options 

The following table lists the command options that you can use for the netpol-analyze command.



Table 7. Command options for performing network policy analysis

 Command options Required or optional Description 

 --path Required The project directory path to scan. 
 -r, --report Required The file name in which to create the compliance report. 
 -c, --connectivity Optional The file name in which to create the connectivity report. 
 -l, --lint Optional The file name in which to create the lint report. 
 -s, --strict Optional Results in command failure (exit status 2) when connectivity risks are found. 







 Example 

The following sample code snippets show how you can use the netpol-analyze command:

ibmcloud cra netpol-analyze --path PATH --report REPORT [--connectivity CONNFILE] [--lint LINTFILE] [--strict]

ibmcloud cra np --path ./sampleDir --report netpol-report.json --strict





 Network config analyzer image
During boot several hashes of components and measures of code are taken and added to the attestation record. To further protect this attestation record, the record is encrypted with the public key that the auditor provided. By doing so, only the auditor is in the position to decrypt the attestation record and can validate that the workload that is deployed in the enclave is the expected and untampered version of the workload that is expected to be deployed into the Hyper Protect Virtual Servers for VPC instance.

Zoom

![Figure showing the attestation process](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc/images/vsi_se_attestationrecord.png)

Figure 1. Attestation process





 Next steps 



* [Creating an instance by using the UI](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-virtual-servers)
* [Creating an instance by using the CLI](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-virtual-servers&interface=cli)
Container Registry CLI stops returning security status results in lists by default from version 1.0.0 

From IBM Cloud® Container Registry CLI plug-in version 1.0.0, when you use the ibmcloud cr image-list and ibmcloud cr image-digests commands to list images, they return Vulnerability Advisor security status results only if you use the --va option.

The [ibmcloud cr image-list](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_list) and [ibmcloud cr image-digests](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_digests) commands currently return the security status of each image by default. Some users store many images in the registry, and returning security status for every image when listing takes more processing time, which can lead to a poor experience and a smaller limit on the maximum number of images that can be listed.

To improve the user experience, a new major version, version 1.0.0, of the IBM Cloud Container Registry CLI plug-in changes the default behavior for the ibmcloud cr image-list and ibmcloud cr image-digests commands so that they return Vulnerability Advisor security status results only if you use the --va option.



  Action required now 

If you want to continue to receive security status with your lists, prepare to upgrade by adding the new --va option to your commands.

If you require security status with your lists, add the --restrict option when you're using the ibmcloud cr image-list and ibmcloud cr image-digests commands to receive just the information that you require.

If you are an API user and require security status with your lists, ensure that you are restricting the repositories that you are requesting to ensure that you receive list results quickly and reliably.
RA-5 (a) <br><br> * Check whether DevSecOps Toolchain scans build artifacts to identify vulnerabilities<br> * Check whether Container Registry Vulnerability Advisor scans for critical or high vulnerabilities in the system at least every # day(s)<br> * Check whether DevSecOps Toolchain validates code against Center for Internet Security (CIS) Docker benchmarks to ensure container runtimes are configured securely<br> * Check whether DevSecOps Toolchain passes dynamic code scan to identify vulnerabilities in deployed artifacts<br> * Check whether DevSecOps Toolchain scans source code and their dependencies to identify vulnerabilities<br> * Check whether DevSecOps Toolchain source code contains no secrets<br> * Check whether DevSecOps Toolchain passes static code scan to identify vulnerabilities in source code<br><br><br> 
 RA-5 (b) <br><br> * Check whether DevSecOps Toolchain scans build artifacts to identify vulnerabilities<br> * Check whether Container Registry Vulnerability Advisor scans for critical or high vulnerabilities in the system at least every # day(s)<br> * Check whether DevSecOps Toolchain validates code against Center for Internet Security (CIS) Docker benchmarks to ensure container runtimes are configured securely<br> * Check whether DevSecOps Toolchain passes dynamic code scan to identify vulnerabilities in deployed artifacts<br> * Check whether DevSecOps Toolchain scans source code and their dependencies to identify vulnerabilities<br> * Check whether DevSecOps Toolchain source code contains no secrets<br> * Check whether DevSecOps Toolchain passes static code scan to identify vulnerabilities in source code<br><br><br>
Contingency Planning (CP) [CP-2 Contingency Plan](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-cp-2) <br>[CP-7 Alternate Processing Site](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-cp-7) 
 System and Communications Protection (SC) [SC-6 Resource Availability](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-sc-6) 







 14. Use endpoint detection and remediation (EDR) tooling to detect malicious code 

Requirement: Use endpoint detection and remediation (EDR) tooling that is effective at detecting malicious code in a cloud environment.

Purpose & value: Malicious code includes viruses, worms, Trojan horses, and spyware. The presence of malicious code puts the operation of your service and the customer data you process at risk. It is important to run regular, automated scans of the components of your service to detect these vulnerabilities so that they can be mitigated.

There are many EDR solutions for virtual server instances such as CrowdStrike and Carbon Black. For Kubernetes, relevant tooling includes StackRox, NeuVector, Sysdig Secure, and Twistlock.

Most Relevant Controls:



Table 14. Related controls for business continuity and disaster recovery

 Family Control 

 System and Information Integrity (SI) [SI-3 Malicious Code Protection](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-si-3) 







 15. Regularly scan for open ports / protocols 

Requirement: Regularly scan for open ports / protocols, and ensure only those ports / protocols needed by your service are open.

Purpose & value: As part of the principal of least privilege, you should only open the minimum number of ports / protocols that are needed by your service. Open ports / protocols not needed by your service enable unnecessary threat vectors.
* Customer wants to identify specific actions to eliminate risks due to cyberthreats, vulnerabilities, or non-compliant configurations.
* Customer wants to achieve faster time to detection with machine learning by analyzing volumes of data to understand good behavior and identify anomalies.
* Customer wants to reduce overall compliance costs due to automated controls and assessments.
* Customer wants to eliminate blind spots by viewing multidimensional grouping of assets across each location, organization, and application group in hybrid cloud.
* Customer wants to build and enforce security and compliance policies based on predictive analytics engine that uses network traffic flows across all applications.







 Key benefits to customers 

The key benefits that are provided by Caveonix RiskForesight include:



* Eliminating blind spots, by viewing multidimensional grouping of assets across each location, organization, and application group in hybrid cloud.
* Building and enforcing security and compliance policies based on predictive analytics engine that uses network traffic flows across all applications.
* Quickly identifying required actions to eliminate risks due to cyberthreats, vulnerabilities, or non-compliant configurations.
* Proactively managing the overall risks within hybrid cloud before they can be used.
* Maintaining a “full-stack” understanding of the workload vulnerabilities and configuration issues at the infrastructure, platform, and application level in the context of threats and compliance requirements.
* Enabling the enterprise to implement the National Institute of Standards and Technology (NIST) proactive Risk Management Framework.
SA-15 (a) <br><br> * Check whether DevSecOps Toolchain scans build artifacts to identify vulnerabilities<br> * Check whether DevSecOps Toolchain verifies source code branch protection rules to enforce security policies<br> * Check whether DevSecOps Toolchain validates code against Center for Internet Security (CIS) Docker benchmarks to ensure container runtimes are configured securely<br> * Check whether DevSecOps Toolchain passes dynamic code scan to identify vulnerabilities in deployed artifacts<br> * Check whether DevSecOps Toolchain scans source code and their dependencies to identify vulnerabilities<br> * Check whether DevSecOps Toolchain source code contains no secrets<br> * Check whether DevSecOps Toolchain passes static code scan to identify vulnerabilities in source code<br> * Check whether DevSecOps Toolchain collects software bills of materials (SBOM) to provide transparency in build artifacts<br> * Check whether DevSecOps Toolchain passes unit tests to validate all code changes<br> * Check whether DevSecOps Toolchain passes acceptance tests to validate every deployment<br> * Check whether DevSecOps Toolchain signs build artifacts to attest their provenance<br> * Check whether DevSecOps Toolchain deployment has approved change documentation including security impact analysis<br><br><br> 







 NIST supplemental guidance 

Development tools include, for example, programming languages and computer-aided design (CAD) systems. Reviews of development processes can include, for example, the use of maturity models to determine the potential effectiveness of such processes. Maintaining the integrity of changes to tools and processes enables accurate supply chain risk assessment and mitigation, and requires robust configuration control throughout the life cycle (including design, development, transport, delivery, integration, and maintenance) to track authorized changes and prevent unauthorized changes.
* Allows setting openssl using the OPENSSL_SECLEVEL environment variable to support old certificates.
* Creation of a more robust image ID to avoid unnecessary image rescans.
* Added malware detection.







 5 February 2021 

Importing Prometheus alert rules
: You can now import Prometheus alert rules.

Dashboard enhancements
: The following dashboard enhancements have been released:



* You can edit the dashboard scope within the panel editor.
* You can set a dashboard template as the team entry point.







 4 February January 2021 

Secure support for enhanced activity audit filters
: The noise-reduction filter has been improved to automatically filter duplicate entries in the feed with a high number of occurances.





 31 January 2021 

Authentication token configuration
: You can configure the authentication token that is allowed in a monitoring instance when you use Python scripts or the Monitoring REST API to manage resources. By default, you can use an IAM token or a Monitoring API token. However, you can restrict the monitoring instance to only allow IAM tokens. [Learn more](https://cloud.ibm.com/docs/monitoring?topic=monitoring-iam_instance_auth).





 28 January 2021 

Secure support for Node Image Analyzer
: V0.1.9 is available with the following changes:



* Added support for running the analyzer in non-Kubernetes environments.
* Fixed an issue scanning images processed on GKE clusters using Docker and Containerd.
* Fixed an issue that prevented images without full tags from being processed on OpenShift.
* Improved version detection for Logback, SpringFramework, and Tomcat Java packages.
* Fixed issues when an incorrect Docker socket path was provided.







 5 January 2021 

Improved alerts
: The alert interface has been improved for faster browsing and easier management.





 23 December 2020 

Secure support for Jenkins
: Plug-in V2.1 is available with the following changes:



* Improved scanning performance and execution.
* Proxy support for master and worker nodes.







 16 December 2020 

Secure support for Node Image Analyzer
: V0.1.7 is available.
This command copies the OCI image that you previously pulled, uses your public key to encrypt the image, and saves the encrypted image to a different local file. Consider naming the encrypted image <source_image>_encrypted for easy identification.

skopeo copy --encryption-key jwe:./mypubkey.pem <source_image>:<tag> <source_image>_encrypted:<tag>
7. Optional: To locally verify that the image is encrypted, you can try to decrypt the image with an incorrect key.



1. Generate a new private key.

openssl genrsa --out wrongkey.pem 1024
2. Attempt to use this new key to decrypt the image. The decryption command fails because the incorrect private key was specified.

skopeo copy --decryption-key ./wrongkey.pem <source_image>_encrypted:<tag> <source_image>_decrypted:<tag>



8. Optional: [Push the encrypted image to IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-startedgs_registry_images_pushing), which supports encrypted OCI images.
9. Specify the encrypted image in your app deployment. For example, if you pushed the encrypted image to IBM Cloud Container Registry, you can follow the example in [Deploying containers from an IBM Cloud Container Registry image to the default Red Hat OpenShift project](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesnamespace). When you create the deployment in your cluster, the container runtime uses the private decryption key in the /etc/crio/keys/synced directory to decrypt the image before running it.
10. For any subsequent images that you want to encrypt, you can either use the same public key to encrypt the images with Skopeo, or repeat these steps to use a different public and private key pair.
// Partial: RA-5(a) Scans for vulnerabilities in the information system and hosted applications Assignment: organization-defined
// frequency and/or randomly in accordance with organization-defined process] and when new vulnerabilities potentially affecting
// the system/applications are identified and reported;
// Partial: RA-5(b). Employs vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts
// of the vulnerability management process by using standards for:..
// Partial: SI-7(12) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | INTEGRITY VERIFICATION
// The organization requires that the integrity of Assignment: organization-defined user-installed software] be verified prior
// to execution.
// Control passed if:
// 1- the script is one of the blessed ones AND
// 2- the status is passed OR
// 3- the status is failed AND issues have been opened AND there are no expired issues AND prod CR approved manually
"evidence_type_id": "com.ibm.container_images",
"version": "1.0.0",
"date": "2020-05-06T12:00:00Z", // date of task run
"origin": {
"url":"https://us-south.git.cloud.ibm.com/open-toolchain/compliance-pipelines/-/blob/master/definitions/mytask.yaml", // where the task is taken from
"version": "423792" // commit id representing the task version used to produce the evidence
}
"toolchain_crn": "crn:v1:bluemix:public:toolchain:us-south:a/190e0b4ce4cd013159917665213ddc51:7467a214-f404-4e23-acab-2e57e935d138::" // CRN of the toolchain