Assess Vulnerabilities and Misconfigurations in CICD Pipelines

Document created by Sean Nicholson Employee on Sep 16, 2019Last modified by Sean Nicholson Employee on Oct 8, 2019
Version 5Show Document
  • View in full screen mode

Who is this written for? 

This document is to provide a flow of how to integrate Qualys Virtual Scanner Appliance into your DevOps pipelines. This is a tool, vendor, and cloud environment agnostic approach that will outline what calls you need to make to perform specific actions in your pipeline for building images, scanning them, and make approval decisions based on the scan results via API calls. This document focuses on the instance and virtual machine image building, while the logic behind some of the calls listed are similar to a container image pipeline, the endpoints for Qualys API for Container Security are different than those shown here. The Container Image Build Pipeline documentation and flow will be covered in another document. 

 

Summary 

This document outlines how to implement vulnerability and compliance scanning in your CICD pipeline using a Qualys Scanner Appliance, physical or virtual. Looking at where in the pipeline to integrate and how to set thresholds for ensuring virtual machine builds adhere to your security governance requirements. This document will cover what API calls are needed, what information is needed for the Qualys API calls, and how to process the responses. 

Depending on your internal processes and requirements there may be a need to scan more than once. You may implement scanning as part of the virtual machine image building phases or in your testing and validation phase. The idea is to implement a set of standards that must be met for an image build to pass. This helps ensure that machines deployed from these approved images are free of critical vulnerabilities and meet the company's security configuration benchmarks. 

 

Design Considerations 

When to perform scans? 

 Vulnerability and compliance scanning may be integrated into the test or verify phases of your CI/CD pipelines. Almost all will need to build vulnerability and compliance scanning into testing and validation steps of the image building process to help ensure that the virtual machines that are deployed from those images contain the latest software patches, are as free as possible of critical vulnerabilities, meet the security configuration requirements, and contain all the agents required by both ops and security. If the required minimums are met for image building requirements, then the image will pass and can then be used for deploying images.  

 

Base Images 

It is recommended to implement scanning as part of the base image creation processes and use the results to pass or fail a build. If a build fails because of the vulnerability scan results, the virtual machine can have patches applied and rescanning of the system X number of times. This iterative approach will ensure the base image builds contain all available OS patches at build time and ensure the virtual machines images do not contain vulnerabilities that violate the established thresholds for image approval.   

This is a great opportunity to ensure virtual machine used to create base images are also hardened to the security benchmarks used by the company for configuration compliance. This can be accomplished by using Qualys Policy Compliance scanning in the pipeline and using the results to assist in determining pass/fail of build jobs for virtual machine images. If a virtual machine passes the compliance scan, this will ensure the images created from the virtual machine will already be hardened to the organization’s configuration compliance standards. 

Scanning in the build pipeline 

As part of the application team build processes, just like the virtual machine base OS image building process, vulnerability and compliance scanning should be implemented. This will help ensure that the virtual machines being built contains no known critical vulnerabilities and that no configuration changes are made that violate the established security governance standards. This will ensure that the virtual machines being built, are compliant with the organization’s information security requirements.  

 

Scanner Placement 

It is recommended to follow best practices for deploying Qualys scanners in your environment. This includes not having a firewall between the scanner and the virtual machine, if this is not possible, allowing full ingress to the virtual machine from the scanner is recommended as well as ensuring the number of firewalls between the scanner and virtual machine is kept to a minimum. To ensure faster scan times, it is recommended to place a scanner in the network or as close as possible to the network where the virtual machines will be created is recommended. Placing a scanner on the same network or in the same VPC of the virtual machines that will be scanned will help ensure the most accurate scan results and will simplify troubleshooting of any encountered issues with performing scans.  

 

Where Qualys API commands run 

Decide how Qualys API commands will run in your virtual machine image creation pipeline. Some options are to run the commands on the virtual machine, via the pipeline management scripts, or via a serverless function, or a tool such as Jenkins. Defining where the Qualys API commands will run will create the framework of the settings and command options needed to execute the commands.  

Running Scans 

Vulnerability Management Host Assets  

In order to perform IP address scans on target instances, the IP address must be added to or already included in the Qualys subscription. You can check if the IP is in your Qualys subscription host assets by pulling a list of the IPs as shown below. Iterate the list for IP and IP_RANGE entries. If the IP to be scanned is not in your subscription, then it can be added as shown below.

Static IP Address Space 

If the subnet where images are being built and instantiated is known, this subnet / CIDR block can be added to the Qualys subscription host assets. This is the recommended approach which provides coverage of known network configuration information for the area where instances will be scanned. If your build pipelines are run in multiple networks, network segments, or cloud environments and the IP address subnets are known, then all should be added to your host assets licenses.  

Adding of the host asset IP address subnets is required in order to scan by IP address or to add to a Qualys Vulnerability Management Authentication Record. Examples of adding or removing IP addresses from Authentication Records is shows below in the Authentication Records section.  

Ephemeral / Non-static 

For environments where this is not a predefined know range of IP addresses that instances will be assigned, the instance IP address will need to be added to the subscription prior to adding the IP address to an Authentication Record or running a vulnerability or compliance scan of the instance. The IP address of the instance can be read from the virtual machine metadata or by extracting this from the virtual machine configuration. Once the IP address is known, it can be added to the Qualys Vulnerability Management and/or Policy Compliance Host Assets. 

Adding Host Asset IP and Enable Vulnerability Management and/or Policy Compliance 

Required headers: 

  • Accept: text/xml 
  • Content-Type: text/xml 

X-Requested-With: Curl Parameters for API request 

Type  

 Parameter List 

Request  

action=add,list 

Enable VM / PC   

enable_vm=1

enable_pc=1

enable_vm=1&enable_pc=1

IP Address(es)   

add_ips=

 

List Host Assets IPs

Example API call for listing IP addresses from Host Assets 

(QualysPlatformURL)/api/2.0/fo/asset/ip/?action=list 

Enable Vulnerability Management Host Assets 

Example API call for adding IP addresses to Vulnerability Management Host Assets 

(QualysPlatformURL)/api/2.0/fo/asset/ip/?action=add&enable_vm=1&ips=10.0.0.1 

Enable Vulnerability Management and Policy Compliance Host Assets 

Example API call for adding IP addresses to Vulnerability Management Host Assets 

(QualysPlatformURL)/api/2.0/fo/asset/ip/?action=add&enable_vm=1&enable_pc=1&ips=10.0.0.1 

Information on administering assets using the Qualys API can be found Qualys API VM & PC User Guide in Chapter 7 - Assets 

 

Authentication Records 

Known IP Address space 

If the CIDR block for building virtual machines is known, the CIDR block can be added to the Qualys Authentication Records 

Ephemeral IP Addresses 

If the build pipeline is running instances in an environment where the IP addresses are being assigned by the public cloud provider, the ephemeral IP address of the instance will need to be added to the authentication record prior to running a vulnerability management or policy compliance scan. It is recommended to perform a cleanup of the authentication record assigned IPs once the pipeline scanning is completed.  

This will also require a lookup of the authentication record ID or specifying this for a specific pipeline and then updating the authentication record target IP address 

API Commands to add and remove IP address(es) or IP address blocks 

Required headers: 

  • Accept: text/xml 
  • Content-Type: text/xml 
  • X-Requested-With: Curl 

Parameters for API request 

Type  

 Parameter List 

Request  

action=update 

Authentication Record ID   

ids=1234567890 

IP Address(es)   

add_ips= 

Information on administering Authentication Records using the Qualys API can be found Qualys API VM & PC User Guide in Chapter 5 – Scan Authentication 

 

Adding IP Addresses 

Unix/Linux 

Examples of adding an IP address to a Unix authentication record 
(Qualys Platform URL)/api/2.0/fo/auth/unix/?action=update&ids=1234567890&add_ips=1.2.3.4 

Windows 

Examples of adding an IP address to a Windows authentication record 
(Qualys Platform URL)/api/2.0/fo/auth/windows/?action=update&ids=1234567890&add_ips=1.2.3.4 

Removing IP Addresses 

Unix/Linux 

Example of removing an IP address to a Unix authentication record 
(Qualys Platform URL)/api/2.0/fo/auth/unix/?action=update&ids=1234567890&remove_ips=1.2.3.4 

Windows 

Examples of removing an IP address to a Windows authentication record 
(Qualys Platform URL)/api/2.0/fo/auth/windows/?action=update&ids=1234567890&remove_ips=1.2.3.4 

 

Vulnerability Management Scans 

Qualys scanner appliances can run vulnerability scans and / or compliance scans on a system’s IP address(es). Once an instance is created from an image and has an IP address, the virtual machine instance can be scanned.  

Vulnerability scans can be run either as an authenticated scan with administrator/root privileges or non-authenticated. Compliance scans will only run via authenticated scans with administrator/root privileges. 

Required headers: 

  • Accept: text/xml 
  • Content-Type: text/xml 
  • X-Requested-With: Curl 

Parameters 

Type  

 Parameter List 

Request  

action=launch (required), echo_request, runtime_http_header 

Scan Title   

scan_title 

Option Profile   

option_id or option_title 

Scanner Appliance  

iscanner_id or iscanner_name, ec2_instance_ids 

Processing Priority  

priority 

Asset IPs/Groups  

ip, asset_group_ids, asset_groups, exclude_ip_per_scan, default_scanner, scanners_in_ag 

Network  

ip_network_id (when the Network Support feature is enabled) 

Client   

client_id and client_name (only for Consultant type subscriptions) 

Information on running scans using the Qualys API can be found Qualys API VM & PC User Guide in Chapter 3 - Scans 

Example API call 

Vulnerability Scans 

Run Vulnerability Scan on virtual machine using the virtual machine IP address 
(QualysPlatformURL)/api/2.0/fo/scan/?action=launch& iscanner_id=123456789&scan_title=Candidate%20Image%20Scan123456789098&option_id=1234567890&ip=1.2.3.4&priority=5 

Policy Compliance Scans 

 Run Vulnerability Scan on virtual machine using the virtual machine IP address 
(QualysPlatformURL)/api/2.0/fo/scan/compliance/?action=launch& iscanner_id=123456789&scan_title=Candidate%20Image%20Scan123456789098&option_id=1234567890&ip=1.2.3.4&priority=5 

Example Response 

<?xml version="1.0" encoding="UTF-8" ?> 

<!DOCTYPE SIMPLE_RETURN SYSTEM "https://QualysAPI-URL/api/2.0/simple_return.dtd"> 

<SIMPLE_RETURN> 

    <RESPONSE> 

        <DATETIME>2019-06-12T18:10:43Z</DATETIME> 

        <TEXT>New vm scan launched</TEXT> 

        <ITEM_LIST> 

            <ITEM> 

                <KEY>ID</KEY> 

                <VALUE>15737591</VALUE> 

            </ITEM> 

            <ITEM> 

                <KEY>REFERENCE</KEY> 

                <VALUE>scan/1563559842.37591</VALUE> 

            </ITEM> 

        </ITEM_LIST> 

    </RESPONSE> 

</SIMPLE_RETURN> 

 

Check Scan Status 

Use the Reference Value in the response to query for the status of the scan. A loop checking for completed scan status should be run to ensure the scan has completed prior to querying for the scan results. 

Required headers: 

  • Accept: text/xml 
  • Content-Type: text/xml 
  • X-Requested-With: Curl 

Body Parameters 

Type  

 Parameter List 

Request  

action=list(required), echo_request 

Show/Hide Information 

show_ags=0, show_status=1, show_op=0 

Scan List Filters  

scan_ref, state, processed, type, target, user_login, 

launched_after_datetime, launched_before_datetime, 

scan_type=certview, scan_type=ec2certview, client_id and 

client_name (only for Consultant type subscriptions) 

Information on running scans using the Qualys API can be found Qualys API VM & PC User Guide in Chapter 3 - Scans 

Example API Call 

(QualysPlatformURL)/api/2.0/fo/scan/ 

Example Response 

<?xml version="1.0" encoding="UTF-8" ?> 

<!DOCTYPE SCAN_LIST_OUTPUT SYSTEM "https://qualysapi.qg2.apps.qualys.com/api/2.0/fo/scan/scan_list_output.dtd"> 

<SCAN_LIST_OUTPUT> 

    <RESPONSE> 

        <DATETIME>2019-06-12T18:014:16Z</DATETIME> 

        <SCAN_LIST> 

            <SCAN> 

                <REF>scan/1563559842.12365</REF> 

                <TYPE>API</TYPE> 

                <TITLE> 

                    <![CDATA[Pipeline Scan]]> 

                </TITLE> 

                <USER_LOGIN>xxxxxxxxxx</USER_LOGIN> 

                <LAUNCH_DATETIME>2019-06-12T18:10:42Z</LAUNCH_DATETIME> 

                <DURATION>00:15:16</DURATION> 

                <PROCESSING_PRIORITY>0 - No Priority</PROCESSING_PRIORITY> 

                <PROCESSED>1</PROCESSED> 

                <STATUS> 

                    <STATE>Finished</STATE> 

                </STATUS> 

                <TARGET> 

                    <![CDATA[i-1234567890ab]]> 

                </TARGET> 

            </SCAN> 

        </SCAN_LIST> 

    </RESPONSE> 

</SCAN_LIST_OUTPUT> 

<!-- CONFIDENTIAL AND PROPRIETARY INFORMATION. Qualys provides the QualysGuard Service "As Is," without any warranty of any kind. Qualys makes no warranty that the information contained in this report is complete or error-free. Copyright 2019, Qualys, Inc. //--> 

 

Parse Scan Results 

Get list of QIDs 

To obtain scan results via the Qualys API, you must query the Scans API endpoint, the host detection API endpoint, or the Reports API endpoint. This example will query for the Scans API Endpoint since we already have all the information from the previous steps to query this endpoint and do not have to wait on much backend processing of the results.   

Query for the list of results using the output_format=json_extended option to retrieve the list of scan results with vulnerability information returned in the scan findings. The vulnerability findings start on the third item of the returned list of JSON objects. Iterate the list of results and capture the QID field, Severity, related CVSS information, and additional threat information. If you choose the “output_format=json” option, you can use the QID to query the Qualys Knowledge Base for additional information on the QID. An example of this will be covered in the next section. 

Required headers: 

  • Accept: text/xml 
  • Content-Type: text/xml 
  • X-Requested-With: Curl 

Body Parameters 

Type  

 Parameter List 

Request  

action=fetch(required), echo_request 

output_format={csv|json| 

csv_extended| 

json_extended} 

(Optional) output_format=json_extended 

Specify whether to return scan results in JSON/CSV 

Default: results returned as CSV 

Scan List Filters  

Example query uses scan_ref=scan/1234567890.12345 

mode={brief|extended} 

Example query uses mode=extended  

The verbosity of the scan results 

details: brief (the default) or extended. The brief output includes 

this information: IP address, DNS hostname, NetBIOS hostname, 

QID and scan test results if applicable. The extended output 

includes the brief output plus this extended information: 

protocol, port, an SSL flag (“yes” is returned when SSL was used 

for the detection, “no” is returned when SSL was not used), and 

FQDN if applicable. 

Information on running scans using the Qualys API can be found Qualys API VM & PC User Guide in Chapter 3 - Scans 

Example API Call 

(QualysPlatformURL)/api/2.0/fo/scan/?action=fetch&scan_ref=scan/1234567890.12345&mode=extended&output_format=json_extended 

Example Response  

Example finding for output_format=json&mode=extended (json return in list format [{scan info}, {ip info}, {finding1}, {finding2}….((findings info to length of list) - 1),{scan and host summary}) 

[{"ip":"1.2.3.4","dns":"ec2-1-2-3-4.us-east-2.compute.amazonaws.com","netbios":null,"qid":6,"instance":null,"result":"IP address\tHost name\n1.2.3.4\tec2-1-2-3-4.us-east-2.compute.amazonaws.com"} 

 

Example finding for output_format=json_extended&mode=extended (json return in list format [{scan info}, {ip info}, {finding1}, {finding2}….((findings info to length of list) - 1),{scan and host summary}) 

{"ip":"1.2.3.4","dns":" ec2-1-2-3-4.us-east-2.compute.amazonaws.com ","netbios":null,"os":"Linux 2.6","ip_status":"host scanned, found vuln","qid":82040,"title":"ICMP Replies Received","type":"Ig","severity":"1","port":"","protocol":"","fqdn":"","ssl":"no","cve_id":null,"vendor_reference":null,"bugtraq_id":null,"cvss_base":null,"cvss_temporal":null,"cvss3_base":null,"cvss3_temporal":null,"threat":"ICMP (Internet Control and Error Message Protocol) is a protocol encapsulated in IP packets. ICMP's principal purpose is to provide a protocol layer that informs gateways of the inter-connectivity and accessibility of other gateways or hosts. \r\n \r\nWe have sent the following types of packets to trigger the host to send us ICMP replies: \r\n \r\nEcho Request (to trigger Echo Reply) \r\nTimestamp Request (to trigger Timestamp Reply) \r\nAddress Mask Request (to trigger Address Mask Reply) \r\nUDP Packet (to trigger Port Unreachable Reply) \r\nIP Packet with Protocol>= 250 (to trigger Protocol Unreachable Reply)\r\n \r\nListed in the \"Result\" section are the ICMP replies that we have received.","impact":null,"solution":null,"exploitability":null,"associated_malware":null,"results":"ICMP Reply Type\tTriggered By\tAdditional Information\nEcho (type=0 code=0)\tEcho Request\tEcho Reply\nTime Stamp (type=14 code=0)\tTime Stamp Request\t17:43:24 GMT\nUnreachable (type=3 code=3)\tUDP Port 1\tPort Unreachable\nUnreachable (type=3 code=3)\tUDP Port 18354\tPort Unreachable\nUnreachable (type=3 code=3)\tUDP Port 5060\tPort Unreachable\nUnreachable (type=3 code=3)\tUDP Port 11000\tPort Unreachable\nUnreachable (type=3 code=3)\tUDP Port 2001\tPort Unreachable\nUnreachable (type=3 code=3)\tUDP Port 6912\tPort Unreachable\nUnreachable (type=3 code=3)\tUDP Port 464\tPort Unreachable\nUnreachable (type=3 code=3)\tUDP Port 7300\tPort Unreachable\nUnreachable (type=3 code=3)\tUDP Port 1812\tPort Unreachable\nUnreachable (type=3 code=3)\tUDP Port 52352\tPort Unreachable","pci_vuln":"no","instance":null,"os_cpe":null,"category":"TCP\/IP"} 

 

Querying the Qualys Knowledge Base 

 To query the Qualys Knowledge Base API endpoint, submit a query with the body parameters qid=12345 or quid=12345,23456,34567 to return information on a single QID or a list of QIDs. This body parameter will accept a list of QIDs so you can either iterate the list of QIDs detected in the scan results and make a single call per QID or you can pass all the QIDs from the scan results and iterate the returned XML information. The implementation here is based on your own internal requirements and build failure logic gates. By submitting  

If you are failing a build on a single Severity 4 or 5 QID, you may choose to iterate the list of QID with a single call to the knowledge base and if a severity if 4 or 5, fail the build.  

If you are failing a build on total number of critical vulnerabilities or some other metric that looks at an average, median, or high water mark, then return the whole list of QIDs in a single query should be more efficient. 

The Associated CVEs and CVSS scores for the QID are also included in the results with the body parameter details=Basic, this can also be used to decide to pass or fail a build as well. Example results are shown below. 

Required headers: 

  • Accept: text/xml 
  • Content-Type: text/xml 
  • X-Requested-With: Curl 

Body Parameters 

Type  

 Parameter List 

Request  

action=list(required), echo_request 

Details 

Example Query details=Basic 

(Optional) Show the requested amount of information for each 

vulnerability in the XML output. A valid value is: Basic (default), 

All, or None. Basic includes basic elements plus CVSS Base and 

Temporal scores. All includes all vulnerability details, including 

the Basic details. 

QID 

Example query uses ids= 351425 

This parameter accepts a single QID or a list of QIDs 

ids= 351425 or ids= 351425,156789,125674 

Information on running scans using the Qualys API can be found Qualys API VM & PC User Guide in Chapter 4 – Scan Configuration. 

 

Example API Call 

(QualysPlatformURL)/api/2.0/fo/knowledge_base/vuln/?action=list&details=Basic&ids=351425 

Example Response 

<?xml version="1.0" encoding="UTF-8" ?> 

<!DOCTYPE KNOWLEDGE_BASE_VULN_LIST_OUTPUT SYSTEM "https://QualysAPI-URL/api/2.0/fo/knowledge_base/vuln/knowledge_base_vuln_list_output.dtd"> 

<KNOWLEDGE_BASE_VULN_LIST_OUTPUT> 

    <RESPONSE> 

        <DATETIME>2019-06-12T20:42:01Z</DATETIME> 

        <VULN_LIST> 

            <VULN> 

                <QID>351425</QID> 

                <VULN_TYPE>Vulnerability</VULN_TYPE> 

                <SEVERITY_LEVEL>3</SEVERITY_LEVEL> 

                <TITLE> 

                    <![CDATA[Amazon Linux Security Advisory for openssl: ALAS-2018-1102]]> 

                </TITLE> 

                <CATEGORY>Amazon Linux</CATEGORY> 

                <LAST_SERVICE_MODIFICATION_DATETIME>2018-12-12T09:38:57Z</LAST_SERVICE_MODIFICATION_DATETIME> 

                <PUBLISHED_DATETIME>2018-12-12T09:38:57Z</PUBLISHED_DATETIME> 

                <BUGTRAQ_LIST> 

                    <BUGTRAQ> 

                        <ID> 

                            <![CDATA[103518]]> 

                        </ID> 

                        <URL> 

                            <![CDATA[http://www.securityfocus.com/bid/103518]]> 

                        </URL> 

                    </BUGTRAQ> 

                    <BUGTRAQ> 

                        <ID> 

                            <![CDATA[105609]]> 

                        </ID> 

                        <URL> 

                            <![CDATA[http://www.securityfocus.com/bid/105609]]> 

                        </URL> 

                    </BUGTRAQ> 

                    <BUGTRAQ> 

                        <ID> 

                            <![CDATA[100515]]> 

                        </ID> 

                        <URL> 

                            <![CDATA[http://www.securityfocus.com/bid/100515]]> 

                        </URL> 

                    </BUGTRAQ> 

                </BUGTRAQ_LIST> 

                <PATCHABLE>1</PATCHABLE> 

                <SOFTWARE_LIST> 

                    <SOFTWARE> 

                        <PRODUCT> 

                            <![CDATA[openssl]]> 

                        </PRODUCT> 

                        <VENDOR> 

                            <![CDATA[openssl]]> 

                        </VENDOR> 

                    </SOFTWARE> 

                </SOFTWARE_LIST> 

                <VENDOR_REFERENCE_LIST> 

                    <VENDOR_REFERENCE> 

                        <ID> 

                            <![CDATA[ALAS-2018-1102]]> 

                        </ID> 

                        <URL> 

                            <![CDATA[https://alas.aws.amazon.com/ALAS-2018-1102.html]]> 

                        </URL> 

                    </VENDOR_REFERENCE> 

                </VENDOR_REFERENCE_LIST> 

                <CVE_LIST> 

                    <CVE> 

                        <ID> 

                            <![CDATA[CVE-2018-0495]]> 

                        </ID> 

                        <URL> 

                            <![CDATA[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0495]]> 

                        </URL> 

                    </CVE> 

                    <CVE> 

                        <ID> 

                            <![CDATA[CVE-2017-3735]]> 

                        </ID> 

                        <URL> 

                            <![CDATA[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3735]]> 

                        </URL> 

                    </CVE> 

                    <CVE> 

                        <ID> 

                            <![CDATA[CVE-2018-0739]]> 

                        </ID> 

                        <URL> 

                            <![CDATA[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0739]]> 

                        </URL> 

                    </CVE> 

                </CVE_LIST> 

                <DIAGNOSIS> 

                    <![CDATA[Libgcrypt  allows a memory-cache side-channel attack on ECDSA signatures that can be mitigated through the use of blinding during the signing process in the _gcry_ecc_ecdsa_sign function in cipher/ecc-ecdsa.c, aka the Return Of the Hidden Number Problem or ROHNP. To discover an ECDSA key, the attacker needs access to either the local machine or a different virtual machine on the same physical host.(<A HREF="https://access.redhat.com/security/cve/CVE-2018-0495" TARGET="_blank">CVE-2018-0495 </A>)</P><P>While parsing an IPAddressFamily extension in an X.509 certificate, it is possible to do a one-byte overread. This would result in an incorrect text display of the certificate. This bug has been present since 2006.(<A HREF="https://access.redhat.com/security/cve/CVE-2017-3735" TARGET="_blank">CVE-2017-3735 </A>)</P><P>Constructed ASN.1 types with a recursive definition (such as can be found in PKCS7) could eventually exceed the stack given malicious input with excessive recursion. This could result in a Denial Of Service attack. There are no such structures used within SSL/TLS that come from untrusted sources so this is considered safe.(<A HREF="https://access.redhat.com/security/cve/CVE-2018-0739" TARGET="_blank">CVE-2018-0739 </A>)</P> 

]]> 

        </DIAGNOSIS> 

        <CONSEQUENCE> 

            <![CDATA[Allows unauthorized disclosure of information; allows unauthorized modification; allows disruption of service.]]> 

        </CONSEQUENCE> 

        <SOLUTION> 

            <![CDATA[Please refer to Amazon advisory <A HREF="https://alas.aws.amazon.com/ALAS-2018-1102.html" TARGET="_blank">ALAS-2018-1102</A> for affected packages and patching details, or update with your package manager.<P>Patch:<BR> 

Following are links for downloading patches to fix the vulnerabilities: 

<P><A HREF="https://alas.aws.amazon.com/ALAS-2018-1102.html" TARGET="_blank">ALAS-2018-1102: Amazon Linux (openssl (1.0.2k-16.146.amzn1) on i686)</A><P><A HREF="https://alas.aws.amazon.com/ALAS-2018-1102.html" TARGET="_blank">ALAS-2018-1102: Amazon Linux (openssl (1.0.2k-16.146.amzn1) on x86_64)</A><P><A HREF="https://alas.aws.amazon.com/ALAS-2018-1102.html" TARGET="_blank">ALAS-2018-1102: Amazon Linux (openssl (1.0.2k-16.146.amzn1) on src)</A>]]> 

        </SOLUTION> 

        <CVSS> 

            <BASE>5</BASE> 

            <TEMPORAL>3.7</TEMPORAL> 

            <VECTOR_STRING>CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:P/A:N/E:U/RL:OF/RC:C</VECTOR_STRING> 

        </CVSS> 

        <CVSS_V3> 

            <BASE>6.5</BASE> 

            <TEMPORAL>5.2</TEMPORAL> 

            <VECTOR_STRING>CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H/E:U/RL:O/RC:U</VECTOR_STRING> 

        </CVSS_V3> 

        <PCI_FLAG>1</PCI_FLAG> 

        <THREAT_INTELLIGENCE> 

            <THREAT_INTEL id="5"> 

                <![CDATA[Easy_Exploit]]> 

            </THREAT_INTEL> 

        </THREAT_INTELLIGENCE> 

        <DISCOVERY> 

            <REMOTE>0</REMOTE> 

            <AUTH_TYPE_LIST> 

                <AUTH_TYPE>Unix</AUTH_TYPE> 

            </AUTH_TYPE_LIST> 

            <ADDITIONAL_INFO>Patch Available</ADDITIONAL_INFO> 

        </DISCOVERY> 

    </VULN> 

</VULN_LIST> 

</RESPONSE> 

</KNOWLEDGE_BASE_VULN_LIST_OUTPUT> 

<!-- CONFIDENTIAL AND PROPRIETARY INFORMATION. Qualys provides the QualysGuard Service "As Is," without any warranty of any kind. Qualys makes no warranty that the information contained in this report is complete or error-free. Copyright 2019, Qualys, Inc. //--> 

 

Implementation 

Part of the success criteria in using vulnerability scan results to pass or fail an image build requires the scan results to be available to the DevOps teams when a build fails.  Depending on your implementation, this can be done a variety of ways.  

Examples would be 

  1. Create a scan report and store it in a secure storage and provide a link upon failure of the build 
  1. Provide the list of vulnerabilities names, QIDs, and Severities in the log for the build failure. Optionally, include a list of CVE links as well so they can know what needs to be fixed to comply your organizations security governance policies. This information can be found in the response of the query to Qualys QID Knowledge Base 

 

The decision to automatically pass or fail a build will depend on your own internal security governance and risk tolerances. It is best to work with your DevOps teams to develop these thresholds together. You may end up with different risk tolerances and failure thresholds depending on the application data types and categorizations across business units.  The key to success is cooperation within your organization. Ensure you also look at tracking Key Performance Indicators (KPIs) for the reduction in vulnerabilities in your environments and to track progress of your implementation. This will help show the value of the time spent implementing when it comes time to report progress to management. 

 

Tips for Success 

  1. If just getting started with integrating vulnerability scanning into your pipelines you may decide to implement an iterative approach, where you set a time period and high-water mark of Severity 4 and 5 to fail a build for containing a critical vulnerability. Then as your processes mature, look to add medium severity vulnerabilities to the failure criteria so that over time you work to reduce the number of vulnerabilities in your environment. 
  1. Choose a champion for your organization. Identifying a single team, application pipeline, or Business Unit to work on the initial implementation. Working with a smaller group, initially, will allow for faster implementation and show success quicker as well. This will allow you to resolve any potential design or implementation problems prior to larger adoption. Use the success with this smaller implementation as the success story for a broader implementation across your organization. 

 

 

2 people found this helpful

Outcomes