OS level package analysis
Los mantenedores suelen responder en 6 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
Línea de trabajo
Empieza revisando los tipos de paquetes compatibles actualmente y el flujo de escaneo del proyecto package-analysis; después, haz un inventario de cómo los gestores de paquetes del sistema operativo y las herramientas de compilación o pruebas podrían encajar en los casos de uso solicitados. Para darlo por terminado, sería necesario definir un alcance centrado y acordado para el análisis de paquetes del sistema operativo, en lugar de las varias integraciones propuestas aquí.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
This is a neat idea, but I'm wondering about a few possible areas of improvement:
- What about packages generated by popular open source projects?
- Integrations with existing OS package managers to check for flagged versions of python, ruby, etc scripts?
- Integrations with OS package cluster/build tools to do scans (for example during test runs/qat)
OS vendors have to frequently package up existing python, perl, ruby, rust crates, etc for dependencies on packages. However, they also build a lot of other things that aren't covered here. it would make sense for the package to never be built if it has known malware you've already identified. It would make sense for the package manager not to install the malware or at least warn the user it contains malware.
Some of these things detected will result in a CVE and eventually get caught by projects, but there's a delay.
For context, I run a small BSD project but I'm also thinking about all the k8s pods we use at work running debain/ubuntu/alpine packages.
- Lenguaje dominante
- Go
- Estrellas
- 925
- Forks
- 75
- Merge medio
- 4 d 2 h
- PR fusionados (30 d)
- 3
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de ossf/package-analysis
-
Python execute phase aborts with error_analysis when the package closes stdout (MCP stdio servers)Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 78/100
ossf/package-analysis#1200 ·
Los mantenedores suelen responder en 6 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
ossf/package-analysis#1192 ·
Los mantenedores suelen responder en 6 días
-
OpenSSF Documentation UpdatesAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
ossf/package-analysis#1125 ·
Los mantenedores suelen responder en 6 días
-
4gbAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 5/100
ossf/package-analysis#1123 ·
Los mantenedores suelen responder en 6 días
-
>4 gbAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 10/100
ossf/package-analysis#1122 ·
Los mantenedores suelen responder en 6 días
Todos los issues de ossf/package-analysis
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
-
evener-transcript-v2-upgrade tool still scans transcript files through bufio's 4 KiB default bufferAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
prime-radiant-inc/evener#6370 ·
Los mantenedores suelen responder en 1 día
-
ManageSieve proxy: a backend's NO/BYE greeting is skipped as a capability line and reported as EOFAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Mend: dependency security vulnerability
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
Mend: dependency security vulnerability
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
ManageIQ/manageiq-pods#1476 ·
Los mantenedores suelen responder en 1 día