research(provider): cloud runtime state as a table-keyed json document
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 30/100
Línea de trabajo
Comienza con el proveedor JSON existente y sigue cómo se gestionan los documentos indexados por tabla y el relleno por ausencia. Compara las estructuras de exportación de AWS Config, Azure Resource Graph y GCP Cloud Asset Inventory, y resuelve después el comportamiento de redaction, staleness fail-closed y ausencia de filas descrito en el issue. Se considerará terminado cuando los formatos de exportación compatibles y esos casos límite tengan un comportamiento claro y probado.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Most cloud-compliance policies (CIS, PCI and framework packs) read live cloud state, not a file.
The Tirith side is small: an envelope convention ({"snapshot_version": …, "aws_s3_bucket": [row, …]}) read through the json provider with absence-padding — not a new provider package.
The collector question has a better answer than "build one": AWS Config configuration snapshots,
Azure Resource Graph and GCP Cloud Asset Inventory each emit a keyed JSON inventory inside the
customer's account — Tirith reads a file and never holds a cloud credential, so the project becomes
"read three export formats". An existing multi-cloud inventory tool remains the right general-purpose collector. Open needs:
a redactor (live API rows hold credential reports and key policies), staleness that fails closed,
and the nothing-in-scope decision ("no rows of that table" is the modal case).
- Lenguaje dominante
- Python
- Estrellas
- 167
- Forks
- 47
- Merge medio
- 2 d 9 h
- PR fusionados (30 d)
- 12
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una 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 StackGuardian/tirith
-
good first issue hacktoberfest tests
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
StackGuardian/tirith#381 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
research
Dificultad 1/5 1-3 horas Aptitud para principiantes 78/100
StackGuardian/tirith#356 ·
Los mantenedores suelen responder en 1 día
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
StackGuardian/tirith#302 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
StackGuardian/tirith#299 ·
Los mantenedores suelen responder en 1 día
-
fix(providers): dotted keys are addressable from terraform_plan but not from json/kubernetesAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
StackGuardian/tirith#295 ·
Los mantenedores suelen responder en 1 día
Todos los issues de StackGuardian/tirith
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
modelcontextprotocol/python-sdk#3648 ·
Los mantenedores suelen responder en 1 día
-
docs good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
VenetoStato/giorgio#6 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 1 día
-
Claiming namespace ddalusAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 70/100
EclipseFdn/open-vsx.org#13831 ·
Los mantenedores suelen responder en 1 día