Descubre, evalúa y mitiga las vulnerabilidades conocidas en tus proyectos Java y Python
Eclipse Steady apoya a las organizaciones de desarrollo de software en lo que respecta al uso seguro de componentes de código abierto durante el desarrollo de aplicaciones. La herramienta analiza las aplicaciones Java y Python para:
detectar si dependen de componentes de código abierto con vulnerabilidades conocidas,
evidencia sobre la ejecución de código vulnerable en un contexto de aplicación determinado (mediante la combinación de técnicas de análisis estático y dinámico), y apoya a los desarrolladores en la mitigación de tales dependencias.
En comparación con otras herramientas, la detección está centrada en el código y se basa en el uso, lo que permite una detección y evaluación más precisas que las herramientas que se basan en metadatos. Es una colección de herramientas de análisis del lado cliente, microservicios y front-ends web OpenUI5 enriquecidos.
Inicio rápido
Guía para configurar los servicios de backend de Eclipse Steady.
Requisitos previos
- git
- docker
- docker-compose
Clonar localmente el repositorio Steady
git clone https://github.com/eclipse/steady.git
Personaliza el archivo docker/.env para que se ajuste a tus necesidades, asegúrate de establecer la versión que quieres ejecutar en VULAS_RELEASE.
cp docker/.env.sample docker/.env
En docker/.env debes configurar al menos POSTGRES_USER=, también debes configurar el usuario y la contraseña de HAPROXY así como las credenciales para acceder al frontend de los bugs.
Ahora estás listo para ejecutar el sistema:
(cd docker && docker-compose up -d --build)
Para comprobar si todo se ha iniciado correctamente, comprueba la página http://localhost:8033/haproxy?stats. Todos los puntos finales deberían aparecer en verde (quizás quieras sustituir localhost por el nombre real de tu máquina).
Funciones
- La detección de código vulnerable se realiza descubriendo firmas de método en archivos Java y comparando su código fuente y byte con la versión vulnerable y fija (como se conoce en la confirmación de corrección). Como tal, la detección es más precisa que para los enfoques basados en metadatos (menos falsos positivos y falsos negativos). En particular, es robusto contra la reagrupación, una práctica muy común en el ecosistema Java.
- La evaluación de las dependencias vulnerables por parte de los desarrolladores de aplicaciones y expertos en seguridad es compatible con la información sobre la ejecución potencial y real de código vulnerable. Esta información se basa en el análisis del gráfico de llamadas y en la información de rastreo recogida durante las pruebas JUnit y de integración. Al descender a la granularidad de los métodos individuales, los desarrolladores de aplicaciones reciben la pila de llamadas potencial y real desde el código de la aplicación hasta el código vulnerable.
- La adición de nuevas vulnerabilidades a la base de conocimientos no requiere volver a escanear las aplicaciones. En otras palabras, justo después de una adición a la base de conocimientos, se sabe inmediatamente si las aplicaciones previamente escaneadas están afectadas o no.
- Las propuestas de mitigación tienen en cuenta la parte alcanzable de las dependencias, es decir, el conjunto de métodos que pueden ser potencialmente alcanzados desde la unión del código de la aplicación las ejecuciones reales observadas durante las pruebas. Esta información se utiliza para calcular varias métricas que permiten a los desarrolladores elegir el mejor reemplazo no vulnerable de una dependencia vulnerable (el mejor en cuanto a la no ruptura y con menor probabilidad de regresión).
- Los hallazgos individuales pueden ser eximidos si los desarrolladores llegan a la conclusión de que una vulnerabilidad no puede ser explotada en un contexto de aplicación determinado. Esta información puede ser mantenida de manera auditable (incluyendo la marca de tiempo y la información del autor) y típicamente previene las excepciones de construcción durante los canales CI/CD.
- Los CERT internos de la organización pueden consultar todas las aplicaciones afectadas por una determinada vulnerabilidad. Esta función permite, por ejemplo, a las grandes organizaciones de desarrollo con muchas aplicaciones de software desarrolladas por unidades de desarrollo distribuidas y descentralizadas.
Requisitos
Eclipse Steady tiene una arquitectura distribuida compuesta por un par de microservicios spring Boot, dos frontend web y una serie de escáneres/plugins del lado cliente, que realizan el análisis real del código de aplicación y dependencia en sistemas de compilación o estaciones de trabajo para desarrolladores.
Para compilar/probar todo el proyecto, se necesitan las siguientes herramientas:
- JDK 8
- Maven 3.3+ para el análisis de proyectos Maven utilizando plugin-maven
- Python 3, así como los paquetes pip, virtualenv y setuptools (pip install -r requirements.txt) para el análisis de aplicaciones Python mediante cli-scanner
- Gradle 4 para el análisis de proyectos Gradle utilizando plugin-gradle.
Construir y probar
Eclipse Steady está construido con Maven. Para habilitar el soporte para Gradle, es necesario activar el perfil (-P gradle)
mvn clean install
Durante la fase de instalación de mvn se ejecutan todas las pruebas. Las pruebas de ejecución prolongada se pueden deshabilitar con el indicador:
-DexcludedGroups=com.sap.psr.vulas.shared.categories.Slow
Todas las pruebas se pueden desactivar con el indicador -DskipTests.
Limitaciones
Debido a la falta actual de un mecanismo de autenticación y autorización, NO se recomienda ejecutar los front-end web y los microservicios del lado del servidor en sistemas accesibles desde Internet.
Otras limitaciones:
Los análisis estáticos y dinámicos no se implementan para Python
No se admiten los archivos multi-lanzamiento de Java 9 (las clases por debajo de META-INF/versions simplemente se ignoran)
