Ofrecemos múltiples enfoques para conectar el SCW Trust Agent a su herramienta de gestión de código fuente basada en Git. Cada enfoque tiene sus ventajas y limitaciones, y podemos ayudarle a tomar una decisión basada en el entorno y las políticas específicas de su organización.
Todos los enfoques almacenan metadatos de confirmación solamente, incluyendo:
- Nombre del autor de la confirmación
- Dirección de correo electrónico del autor
- Fecha de la confirmación
- Lista de extensiones de archivo modificadas en la confirmación
- Lista de lenguajes de programación y frameworks asociados a la confirmación basada en los archivos modificados
El Agente de confianza de SCW almacena estos datos resumidos para generar paneles e informes y para realizar acciones de automatización, como optimizar las rutas de aprendizaje de Secure Code Warrior o aplicar la política configurada.
El código fuente se inspecciona para facilitar la detección precisa de marcos, pero nunca se almacena. Sólo se almacenan los resultados del análisis en forma de extensión de archivo o listas de lenguajes y marcos, como se ha descrito anteriormente.
En las instalaciones
Este enfoque proporciona una combinación de flexibilidad y mitigación de riesgos mediante la ejecución de un contenedor dentro de su entorno configurado y gestionado por su equipo. Esto compensa el riesgo de tener una plataforma de terceros conectada directamente a su herramienta de gestión del código fuente.
El contenedor local es configurable y puede funcionar tanto con plataformas de gestión del código fuente basadas en la nube como con plataformas locales. El contenedor local puede ejecutarse con una frecuencia regular para conectarse automáticamente a los repositorios designados y enviar datos resumidos al agente de confianza de SCW. En ningún momento el código fuente de su organización, o las claves para acceder al código fuente de su organización, abandonan su entorno bajo este enfoque.
- Hemos publicado la imagen Docker local en
ghcr.io/securecodewarrior/trust-agent:latest
- La imagen Docker local puede ejecutarse en la plataforma de contenedores de su elección, por ejemplo, Docker, Kubernetes, etc., o dentro de su canalización CI con soporte para contenedores Docker
- Nuestros clientes suelen utilizar uno de los tres enfoques de despliegue siguientes:
- Ejecutar el contenedor de forma programada desde un portátil o estación de trabajo - Suele ser el método más sencillo, pero requiere que el portátil o la estación de trabajo de la persona estén disponibles para seguir ejecutando importaciones regulares. Puede ejecutarse de forma manual o automatizada mediante una herramienta como cron o un programador de tareas.
- Ejecute el contenedor de forma centralizada en la plataforma de contenedores de su organización - Este enfoque permite gestionar la configuración y ejecución del contenedor desde un único punto, donde se configura para conectarse a todas sus plataformas Git e importar datos por lotes de todos los repositorios en bloque. Sin embargo, el espacio en disco del contenedor y el ancho de banda de la red pueden ser un problema si hay un gran número de repositorios o si éstos son de gran tamaño. Se recomienda un volumen de sistema de archivos persistente para el contenedor para reducir el uso de espacio en disco y limitar el tráfico de red para confirmar deltas.
- Ejecutar el contenedor dentro de cada repositorio CI - Este enfoque normalmente requiere un proyecto CI común compartido por todos sus repositorios para ser escalable, pero si esto está disponible, proporciona una solución limpia para configurar el contenedor para todos los repositorios de modo que individualmente ejecuten el contenedor para importar datos. El método específico dependerá en gran medida del enfoque de CI y de las herramientas adoptadas por su organización; el único requisito es que las herramientas de CI sean compatibles con contenedores Docker.
- El contenedor debe estar configurado con:
- Conectividad de red a sus repositorios Git a través de HTTPS
- Conectividad de red a subdominios bajo prod.securecodewarrior.com
- Suficiente espacio en disco para clonar sus repositorios Git
- Tenga en cuenta que se puede montar un volumen persistente para que cada ejecución del contenedor sea un pull incremental en lugar de un clonado completo del repositorio
- Las siguientes variables de entorno deben pasarse al contenedor cuando se ejecuta:
-
SCW_API_KEY
- Su clave SCW Admin API. Siga esta guía para crear su clave Admin API. -
URL_API_SCW
- Su URL del punto final de la API de SCW. Vaya a Configuración del agente de confianza > Git Connections > Add Provider > On-Premises > Setup Details para obtener su URL de punto final específica. A continuación se muestra un ejemplo:REPO_URLS
- Una lista separada por comas de URL de repositorios Git sin espacios. p. ej.https://git.local/projects/project1.git,https://git2.internal/projects/projectX.git
- Tenga en cuenta que actualmente sólo se soportan URLs HTTPS de repositorios Git, por ejemplo
- A continuación se ofrece un método alternativo a la introducción de credenciales en la URL.
-
- Las siguientes variables de entorno son opcionales y pueden pasarse al contenedor cuando se ejecuta para controlar un comportamiento específico:
-
GIT_USERNAME
- Un método alternativo para proporcionar credenciales. Permite especificar el nombre de usuario que se pasará al repositorio durante la autenticación.- Nota: Esto pasará el mismo conjunto de credenciales a todos los repositorios listados en
REPO_URLS
. Si se requieren diferentes credenciales para diferentes repositorios, se necesitará una ejecución de contenedor separada para cada conjunto de credenciales.
- Nota: Esto pasará el mismo conjunto de credenciales a todos los repositorios listados en
-
GIT_PASSWORD
- Un método alternativo para proporcionar credenciales. Permite especificar la contraseña que se pasará al repositorio durante la autenticación. En la mayoría de las plataformas Git, las claves API y los tokens de acceso pueden proporcionarse utilizandoGIT_PASSWORD
sin necesidad de proporcionarGIT_USERNAME
.- Nota: Esto pasará el mismo conjunto de credenciales a todos los repositorios listados en
REPO_URLS
. Si se requieren diferentes credenciales para diferentes repositorios, se necesitará una ejecución de contenedor separada para cada conjunto de credenciales.
- Nota: Esto pasará el mismo conjunto de credenciales a todos los repositorios listados en
-
SKIP_CERTIFICATE_CHECK
- Establecer comotrue
para omitir la verificación del certificado. Esto puede ser necesario cuando se conecta a sistemas con certificados SSL/TLS emitidos internamente, ya que los certificados raíz y emisor no son públicos. A continuación se describen algunos escenarios en los que esto puede ocurrir:- Conexión a servidores internos de gestión de código fuente con certificados SSL/TLS emitidos internamente. Tenga en cuenta que en este escenario el transporte permanece cifrado y la naturaleza interna del tráfico reduce en gran medida la posibilidad de ataques a la red que esta verificación está diseñada para evitar.
- Conexión a servidores SCW en los que se está realizando una inspección o interceptación SSL/TLS y los certificados de servidor SCW SSL/TLS se están sustituyendo dinámicamente por certificados SSL/TLS emitidos internamente.
-
- Ejemplos para pasar variables de entorno a Docker se muestran a continuación. Consulte la documentación para otras plataformas de contenedores.
- Pasar variables de entorno mediante opciones de línea de comandos
docker run --pull=always -e SCW_API_KEY='your_api_key' -e SCW_API_URL='https://trust-agent.prod-us.prod.securecodewarrior.com' -e REPO_URLS='https://service_user:personal_access_token@git.local/projects/project1.git,https://service_user:service_password@git.local/projects/project2.git,https://git2.internal/projects/projectX.git' ghcr.io/securecodewarrior/trust-agent:latest
- Pasar variables de entorno a través de un archivo
docker run --pull=always --env-file env.list ghcr.io/securecodewarrior/trust-agent:latest
- Pasar variables de entorno mediante opciones de línea de comandos
- Sugerimos ejecutar el contenedor local con una frecuencia diaria o semanal, pero la frecuencia puede ajustarse en función de los requisitos específicos de su organización
Aplicación GitHub
Este enfoque es específico para las organizaciones que utilizan GitHub Cloud o GitHub Enterprise Cloud como su herramienta de gestión de código fuente. Implica un proceso sencillo para instalar una aplicación de GitHub que funciona dentro del marco del ecosistema de GitHub y se considera el enfoque más sencillo en general. Sin embargo, la aplicación requiere permisos de lectura para acceder a los contenidos del repositorio con el fin de acceder a los datos de confirmación, aunque Secure Code Warrior sólo almacena metadatos de confirmación resumidos. Cualquier código fuente inspeccionado con el fin de detectar el marco de trabajo se descarta inmediatamente después del análisis y nunca se almacena. Si prefiere que no se inspeccione el código fuente, hágaselo saber a su CSM y podremos desactivar explícitamente este comportamiento, pero tenga en cuenta que esto también desactivará la capacidad de detección de marcos.
- Vaya a la sección Configuración del agente de confianza y haga clic en Añadir proveedor en Conexiones Git
- Haga clic en Conectar en GitHub App
- Haga clic en Añadir en el Paso 1 para abrir el proceso de instalación en una nueva pestaña. Tenga en cuenta que la instalación de la aplicación para una organización de GitHub requiere un administrador de la organización
- Si no es administrador de la organización, podrá solicitar la instalación de la aplicación por parte de un administrador de la organización
- Si es administrador de una organización, siga los pasos para seleccionar los repositorios a los que tendrá acceso la aplicación e instálela en su organización de GitHub
- Una vez instalado, vuelva a la ventana Configuración del Agente de confianza y haga clic en "Autorizar" en el paso 2 para vincular su inquilino de Secure Code Warrior a su organización de GitHub
Carga manual
Este método no requiere una integración directa con su herramienta de gestión de código fuente basada en Git y se basa en un proceso manual ad hoc para exportar metadatos de confirmación resumidos para cargarlos en el Agente de confianza de SCW. Como resultado, es el método preferido para probar el Agente de confianza de SCW, pero sólo da como resultado una instantánea puntual y no es escalable para un gran número de repositorios.
El proceso de carga manual implica la clonación de los repositorios seleccionados en el sistema local y la ejecución de un script de shell proporcionado para generar los resúmenes de confirmaciones que se pueden cargar a través de la interfaz web del Agente de confianza de SCW. Puede ejecutarse manualmente con la frecuencia que elija. En ningún momento el código fuente de su organización, o las claves para acceder al código fuente de su organización, abandonan su entorno bajo este enfoque.
- Clone el repositorio o repositorios Git (dentro de un único directorio principal) que desea importar al Agente de confianza de SCW localmente en su ordenador portátil o estación de trabajo
- Copie la secuencia de comandos de shell proporcionada, que se reproduce a continuación como referencia, en el directorio principal del repositorio o repositorios Git clonados localmente
git-export.sh
SUBDIRS=$(find . -type d -name ".git" -exec dirname {} \;)
BASEDIR=$(pwd)
para SUBDIR en $SUBDIRS hacer
cd $SUBDIR NOMBRE_PROYECTO=$(nombre_base -s .git `git config --get remoto.origen.url`)
echo "Exportando datos de commit para $SUBDIR"
git log --name-only --since="hace 3 años" --no-merges --pretty=format:'- hash: %H authorDate: %aI
authorEmail: %ae
authorName: %an
modifiedFileExtensions:' | sed -e '/^[^ -]/ s/.*\.\(.*\)/ - \1/' | sed -e '/^[^ -]/d' | sed '$!N; /^\(.*\)\n\1$/!P; D' > $BASEDIR/scw_gci_$PROJECT_NAME.yaml
cd $BASEDIR
hecho
- En su portátil o estación de trabajo, cambie el directorio de trabajo al repositorio Git clonado localmente o al directorio padre de los repositorios
- Ejecute el archivo git-export.sh para producir un archivo YAML por repositorio
- La exportación YAML es un resumen de los datos confirmados y puede ser inspeccionado antes de subirlo a la web
- Inspeccione el contenido de los archivos YAML y redacte o elimine cualquier información si es necesario
- Vaya a Configuración del agente de confianza y haga clic en Añadir proveedor en Conexiones Git
- Haga clic en Cargar en Carga manual
- Seleccione el archivo YAML que desea cargar, especifique una organización y un nombre de repositorio y, a continuación, haga clic en Cargar repositorio. El nombre de la organización puede considerarse una carpeta bajo la que agrupar los repositorios. Repita este paso para todos los archivos YAML exportados.
Comentarios
0 comentarios
El artículo está cerrado para comentarios.