MIGRATION NOTICE
Starting with IQ version 152, this lab is available in the in-product CLI
Learn more here: Callflow in IQ CLI - Remediation Prioritization
Description:
Call flow analysis done correctly!
Are you wondering which vulnerability to fix first? This lab, developed in partnership with MuseDev, helps you answer that question.
We have thought a lot about how program execution analysis, or call flow analysis (CFA), can be used to influence prioritization of security vulnerabilities. Vulnerabilities in library code are associated with particular methods. CFA can help determine whether a vulnerable method may be callable from your application code. CFA should only be used as an indicator of what to fix first, please do not use CFA as justification to NOT fix a known vulnerable component or as an indicator of a false positive. This would simply be an incorrect justification.
We have determined there are 5 different use cases for setting priority on fixing security vulnerabilities identified from call graph analysis:
- (1) Vulnerability exists in bill of materials
- (2) Vulnerable method is probably not called
- (3) Vulnerable component is not referenced from “My Code” or any known public entry point
- (4) Vulnerable method can be called from “My Code” or any known public entry point
- (5) Vulnerable method is reachable by user controlled data
With this lab, use case 1 and 4 are now covered. We are constantly improving the data for use case 4 and working towards use cases 2 and 3. Use case 5 is indirectly covered by use case 4 with the distinction that use case 5 is equivalent to use case 4 minus the dataflow (i.e. use case 5 is called vulnerable methods with dataflow). At this time, we are unsure if the performance trade-off is worth the value of solving use case 5.
Usage and Installation:
Download the archive in the downloads section.
Unpack the archive in a folder
Usage:
./evaluate.sh [options]
-i IQ_APP_ID
-n Namespace [,Namespace …] ( Ex: -n “sonatype” will match com.sonatype and sonatype.org)
JAR/Directory
options:
-s IQ_SERVER default: http://localhost:8070
-a IQ_USER:IQ_PASS default: prompted
-t IQ_STAGE default: build
-u CUSTOM_SOURCES default: ./custom-entrypoints.txt
-q IQ_CLI_JAR default: ./nexus-iq-cli-1.83.0-01.jar
-c CALLGRAPH_ANALYZER_JAR default: ./callgraph-analyzer-0.0.7.jar
-k (no argument, keeps CFA files) default: false
-y MY_SONATYPE_AUTH user:pass default: prompted
-i, Application ID for IQ, if the application does not exist one will be created for you
if you have enabled automatic application creation.
-n, Defines the codebase “My Code” that should be considered as an entry point.
-q, Path to the IQ CLI scanner jar file. 1.80.0-01 is provided in this release
-f, Outputs the .graphml file for the call graph.
Example:
./evaluate.sh -i axis2-webapp-1-5 -n org.apache.axis2 examples-benchmark/axis2-webapp-1.5
You will be prompted for your IQ server login AND your my.sonatype.com login.
What happens when I run this thing:
A sequence of events is orchestrated by the evaluate script.
- The application is scanned by IQ CLI and registered in your IQ server, if it does not exist
- A component label “Can_Be_Called” will be added to your system, if it does not exist
- The application’s security findings are retrieved from your IQ server
- The vulnerability signatures for those findings are requested from Sonatype
- Custom entry points are requested from Sonatype
- Call flow analysis is performed
- The application components that have call flow detected are assigned a Can_Be_Called label for that application in your IQ server
- The scanned application inside of your IQ server is triggered for policy re-evaluation
How can I see which findings have call flow in my IQ server:
Without adding a new policy, you can’t.
We have added a component label to the application components that had call flow detected. You will need to:
- Create a label: “Can_Be_Called”
- Create a policy that checks for the “Can_Be_Called” label.
- In my example, I had one policy with a threat level of 10 for any component that had call flow. My thoughts were, if they could be potentially exploited, those should be the highest priority no matter what the CVSS score on the vulnerability. You can configure policies however you see fit, but I caution against creating a mirror policy for each security policy as it quickly gets into policy explosion and more confusing for the consumer. You may also want to add an exclusion to your existing security policies so an issue won’t be reported twice. Below is a picture of my call flow policy and one example of adding an exclusion to an existing security policy. I added the exclusion to all my security policies.
Why is Java the only language supported:
This lab is intended to understand how program analysis can help you prioritize remediation. Given the nature of static and runtime program analysis, it is difficult if not impossible to determine there is no risk in the identified vulnerable component. Please share your insights on the thread below, take our survey, or send comments to bmayhew@sonatype.com if you wish your comments to remain private. We encourage you to have a discussion on the thread below.
QUESTIONS:
- How does this type of analysis help you prioritize your work?
- How did you set up your policies?
- Did you perform an immediate action based on these results?
- What other data would you like to see from this analysis?
- Was the analysis time acceptable?
- How would you integrate this into your environment?
- In order to improve (add) known entry points, would you be willing to share the non proprietary entry points found in your application analysis? This would consist of reflective and framework (spring, struts, rest, …) entry points. (Note: See statement in warnings/caveats section)
SURVEY:
Your feedback is important and will help justify the productization of a feature like this. Please take 3-4 minutes to complete our survey:
Download:
See Callflow in IQ CLI - Remediation Prioritization
WARNINGS/CAVEATS:
This is a LAB and may change without warning. The callgraph_analyser is being updated constantly, so please check back often. If you add yourself as a topic watcher you will know when updates occur.
The vulnerability signatures are NOT up to date with our current security research AND the returned signatures are rate limited.
You may see incomplete results due to rate limiting from the signature server.
To improve future program analysis and to help discover open source (non-proprietary code) application entry points due to reflection and frameworks, this lab will upload a small subset of your non-proprietary program execution flow to Sonatype. This information is not associated with your application or your organization and is used to analyze potential entry point signatures that are outside of your code base.
Help
For questions or help, reply to this thread. Please do not submit company confidential information.