Java - Soot call graph constructor service

Alternative call graph constructor for Java

License

License

Categories

Categories

Java Languages Security Search Business Logic Libraries
GroupId

GroupId

com.sap.research.security.vulas
ArtifactId

ArtifactId

lang-java-reach-soot
Last Version

Last Version

3.1.15
Release Date

Release Date

Type

Type

jar
Description

Description

Java - Soot call graph constructor service
Alternative call graph constructor for Java
Source Code Management

Source Code Management

https://github.com/eclipse/steady/tree/master/lang-java-reach-soot

Download lang-java-reach-soot

How to add to project

<!-- https://jarcasting.com/artifacts/com.sap.research.security.vulas/lang-java-reach-soot/ -->
<dependency>
    <groupId>com.sap.research.security.vulas</groupId>
    <artifactId>lang-java-reach-soot</artifactId>
    <version>3.1.15</version>
</dependency>
// https://jarcasting.com/artifacts/com.sap.research.security.vulas/lang-java-reach-soot/
implementation 'com.sap.research.security.vulas:lang-java-reach-soot:3.1.15'
// https://jarcasting.com/artifacts/com.sap.research.security.vulas/lang-java-reach-soot/
implementation ("com.sap.research.security.vulas:lang-java-reach-soot:3.1.15")
'com.sap.research.security.vulas:lang-java-reach-soot:jar:3.1.15'
<dependency org="com.sap.research.security.vulas" name="lang-java-reach-soot" rev="3.1.15">
  <artifact name="lang-java-reach-soot" type="jar" />
</dependency>
@Grapes(
@Grab(group='com.sap.research.security.vulas', module='lang-java-reach-soot', version='3.1.15')
)
libraryDependencies += "com.sap.research.security.vulas" % "lang-java-reach-soot" % "3.1.15"
[com.sap.research.security.vulas/lang-java-reach-soot "3.1.15"]

Dependencies

compile (8)

Group / Artifact Type Version
com.sap.research.security.vulas : lang-java-reach jar 3.1.15
ca.mcgill.sable : soot jar 3.3.0
de.tud.sse : soot-infoflow jar 2.7.1.1
com.google.guava : guava jar 27.1-jre
javax.validation : validation-api jar 2.0.1.Final
org.apache.logging.log4j : log4j-api jar 2.13.3
org.apache.logging.log4j : log4j-core jar 2.13.3
com.github.spotbugs : spotbugs-annotations jar 4.1.1

test (1)

Group / Artifact Type Version
junit : junit jar 4.13

Project Modules

There are no modules declared in this project.

Eclipse Steady (Incubator Project)

License PRs Welcome Build Status Maven Central CII Best Practices REUSE status

Discover, assess and mitigate known vulnerabilities in your Java and Python projects

Eclipse Steady supports software development organizations in regards to the secure use of open-source components during application development. The tool analyzes Java and Python applications in order to:

  • detect whether they depend on open-source components with known vulnerabilities,
  • collect evidence regarding the execution of vulnerable code in a given application context (through the combination of static and dynamic analysis techniques), and
  • support developers in the mitigation of such dependencies.

As such, it addresses the OWASP Top 10 security risk A9, Using Components with Known Vulnerabilities, which is often the root cause of data breaches: snyk.io/blog/owasp-top-10-breaches

In comparison to other tools, the detection is code-centric and usage-based, which allows for more accurate detection and assessment than tools relying on meta-data. It is a collection of client-side scan tools, microservices and rich OpenUI5 Web frontends.

Read more in our Docs

History

Originally developed by SAP Security Research, the tool is productively used at SAP since late 2016 (but an earlier prototype was available since 2015). In April 2017, the tool became the officially recommended open-source scan solution for Java (and then Python) applications at SAP. As of April 2019, it has been used to perform 1M+ scans of ~1000 Java and Python development projects, and its adoption is growing at a steady pace.

The tool approach is best described in the following scientific papers, please cite these if you use the tool for your research work:

Features

  • Detection of vulnerable code is realized by discovering method signatures in Java archives and comparing their source and byte code with the vulnerable and fixed version (as known from the fix commit). As such, the detection is more accurate than for approaches based on meta-data (less false-positives and false-negatives). In particular, it is robust against rebundling, a very common practice in the Java ecosystem.
  • Assessment of vulnerable dependencies by application developers and security experts is supported by information about the potential and actual execution of vulnerable code. This information is based on call graph analysis and trace information collected during JUnit and integration tests. Going down to the granularity of single methods, application developers are presented with the potential and actual call stack from application code till vulnerable code.
  • The addition of new vulnerabilities to the knowledge base does not require the re-scan of applications. In other words, right after an addition to the knowledge base, it is immediately known whether previously scanned applications are affected or not.
  • Mitigation proposals consider the reachable share of dependencies, i.e., the set of methods that can be potentially reached from application code union the actual executions observed during tests. This information is used to compute several metrics aiming to let developers chose the best non-vulnerable replacement of a vulnerable dependency (best in regards to non-breaking and with least regression likelihood).
  • Individual findings can be exempted if developers come to the conclusion that a vulnerability cannot be exploited in a given application-context. This information can be maintained in an auditable fashion (incl. timestamp and author information) and typically prevents build exceptions during CI/CD pipelines.
  • Organization-internal CERTs can query for all applications affected by a given vulnerability. This feature supports, for instance, larger development organizations with many software applications developed by distributed and de-central development units.

Requirements

Eclipse Steady has a distributed architecture composed of a couple of Spring Boot microservices, two Web frontends and a number of client-side scanners/plugins, which perform the actual analysis of application and dependency code on build systems or developer workstations.

To build/test the entire project, the following tools are needed:

Build and Test

Eclipse Steady is built with Maven. To enable the support for Gradle the profile gradle needs to be activated (-P gradle)

mvn clean install

During the installation phase of mvn all the tests are run. Long-running tests can be disabled with the flag -DexcludedGroups=com.sap.psr.vulas.shared.categories.Slow. All the tests can be disabled with the flag -DskipTests.

Limitations

Due to the current lack of an authentication and authorization mechanism, it is NOT recommended to run the Web frontends and server-side microservices on systems accessible from the Internet.

Other limitations:

  • Static and dynamic analyses are not implemented for Python
  • Static analysis for Java is only supported until Java 8
  • Java 9 multi-release archives are not supported (classes below META-INF/versions are simply ignored)

Todo (upcoming changes)

The following is a subset of pending feature requests:

  • Static and dynamic analysis for Python
  • Support of JavaScript (client- and server-side)
  • UI dashboards for workspaces

Documentation · Support · Contributing · Deploy guide · Scan guide · Vulnerability database · Blog

com.sap.research.security.vulas

Eclipse Foundation

Versions

Version
3.1.15
3.1.14
3.1.13
3.1.12
3.1.11
3.1.10
3.1.9
3.1.8
3.1.7
3.1.6