Sun, 04 May 2025 21:01:15 GMT

Introduction

Previously, deploying applications was as simple as hosting them on a server or a single workstation. We relied on solutions such as Apache and IIS, mostly resolving issues or patching vulnerabilities via updates and hotfixes 🧪. However, things have changed dramatically since 2010—14 years ago—when organizations started to move from traditional VPS installations to cloud-based solutions. This change obviously enhanced security and operational efficiency, but it has also introduced additional challenges and vulnerabilities.

Today, the deployment process is more structured and sophisticated. We're no longer merely delivering applications; we need to understand their precise requirements, the versions in use, and all of their dependencies. This move has made our work more formal and hard, as administering new apps necessitates an extensive knowledge of their architecture and context.

Introduction
Why Container Security Matter?
What is Trivy?
Setting Up Trivy in GitHub Actions
Best Practices
Code
Conclusion

Why Container Security Matter?

Just like an NPM package is created every second, I could argue that CVEs emerge just as quickly—maybe not in a second, but certainly fast. These vulnerabilities emerge to help us identify risks and resolve them before they escalate into serious problems.

A CVE (Common Vulnerabilities and Exposures) is a list of publicly known security vulnerabilities that exist in software or hardware. Each CVE has a unique ID and specifies a specific vulnerability, allowing businesses to discover and address security vulnerabilities before they are exploited.

This table contains a variety of significant software that has had notable CVEs:

Rank	Software	Number of CVEs	Notable Vulnerability Example	Description
1	Linux Kernel	1000+	CVE-2020-25712 (Privilege Escalation)	A core part of many operating systems, the Linux kernel often has numerous vulnerabilities related to hardware interfaces and memory management.
2	Apache HTTP Server	400+	CVE-2017-15715 (Remote Code Execution)	A widely used web server, Apache HTTP Server frequently faces vulnerabilities related to web protocols and server misconfigurations.
3	WordPress	500+	CVE-2018-6389 (Cross-Site Scripting)	Popular CMS with numerous plugins and themes, leading to many security flaws that can affect websites and user data.
4	OpenSSL	200+	CVE-2014-0160 (Heartbleed)	Provides cryptographic functions to many systems; vulnerabilities often involve weak encryption or improper handling of secure communications.
5	Microsoft Windows	1000+	CVE-2020-0601 (Cryptographic Issue)	The world’s most widely used OS has long been a target for a broad range of exploits across services and applications.
6	Java (JDK)	1000+	CVE-2016-0603 (Remote Code Execution)	The Java Development Kit has many vulnerabilities, especially in its older versions, affecting enterprise software globally.
7	Docker	100+	CVE-2019-5736 (Privilege Escalation)	As the leading containerization tool, Docker has numerous vulnerabilities in container security and Docker daemon configurations.
8	Node.js	150+	CVE-2018-12115 (Denial of Service)	Node.js, as a runtime for JavaScript, often has CVEs related to dependency management and security flaws in asynchronous code execution.
9	Adobe Flash	800+	CVE-2015-0313 (Remote Code Execution)	Although no longer supported, Flash once had numerous security issues, often involving memory corruption and exploits via web browsers.
10	Python	200+	CVE-2018-1000800 (Arbitrary Code Execution)	Python’s broad usage across web apps and server environments has made it a common target for vulnerabilities, especially in third-party libraries.

As you can see, the various components of the programs you develop or use as services frequently have a large number of known vulnerabilities. This makes it essential to frequently check for updates and ensure that your services and applications are patched as soon as possible. Failure to do so could result in major problems, particularly when essential applications are in production and adding value to your business. Without regular maintenance, you risk an unexpected failure 💥 that could disrupt operations at any moment.

"The Office" characters playfully mimicking guns with their fingers.

Fortunately, CVE fixes have significantly improved from 2024 to 2025. It’s clear that both organizations and individual developers are increasingly focused on resolving vulnerabilities, aiming to reduce risk and ensure smoother operations. This progress allows for more ☕ coffee time without worrying about critical security gaps. We can only hope that this positive trend continues as we move forward.

What is Trivy?

In terms of security, Trivy offers an effective solution for checking your container images on a regular basis for vulnerabilities. However, as self-hosted applications gain popularity, there is a growing trend of exposing ports for communication via HTTP, UDP, TCP, gRPC, and other protocols, providing interaction with both internal and external systems. This change adds new complexity to securing not only container images but also communication links between services. So exploits became common, turning this into an acknowledged vulnerability.

Trivy also monitors your IaC for missing setups, which might lead to vulnerabilities. For example, a Kubernetes deployment with unchecked container capabilities can be vulnerable to exploits.

Trivy, developed by Aqua Security, is a popular open-source vulnerability scanner designed for modern DevSecOps workflows. Its standout qualities — speed, simplicity, and comprehensive coverage — make it a preferred choice among developers and security professionals alike.

⚡ Fast scanning.

Trivy is designed for performance. It runs rapid scans by caching results locally and utilizing little system resources. This makes it appropriate not only for CI/CD pipelines, but also for local development environments where developers want rapid feedback.

Low latency: Initial scans download vulnerability databases; subsequent scans are nearly instant.
Optimized for CI/CD: Integrates easily with GitHub Actions, GitLab CI, Jenkins, and other tools.

🧩 Simple to use.

One of Trivy's most significant advantages is its ease of use, from installation to execution.
A single binary requires no complex setup. Simply install and start.
Straightforward CLI: A developer-friendly interface that does not require security knowledge.
Quick onboarding: Teams can begin scanning in minutes.

trivy image nginx:latest

# or with docker

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy image nginx:latest

🔐 Comprehensive Scanning Capabilities

Trivy isn't only for container images. It supports a wide range of targets, making it an adaptable tool for safeguarding infrastructure and applications from beginning to finish.

Container Images (Docker, Podman)
Operating System Packages (Debian, Alpine, etc.)
Infrastructure as Code (IaC) (Terraform, Kubernetes manifests, Helm)
Source Code Repositories
SBOM (Software Bill of Materials) support
Git repositories (local or remote)

With Trivy, you can detect:

CVEs (Common Vulnerabilities and Exposures)
Misconfigurations
Secrets (API keys, tokens)
License compliance issues

🔄 Shift Left Friendly

Trivy enables teams to take a "shift-left" security approach, detecting risks early in the development process before they reach production. This results in fewer surprises and less security debt.

📦 Example Use Cases

Scan a Docker image for known vulnerabilities
Audit a Kubernetes YAML file for insecure defaults
Validate Terraform infrastructure for misconfigurations
Check for exposed secrets in your Git repo

In short, Trivy offers a uniform toolkit for scanning across the software lifecycle, delivering useful information at a minimal overhead. Whether you're developing microservices or managing cloud-native infrastructure, Trivy keeps your stack secure without slowing you down.

Setting Up Trivy in GitHub Actions

Let's create a CI pipeline that uses GitHub Actions to run Trivy on each contribution. This allows us to detect and avoid important security issues before they reach production.

In a fast-paced development environment, it's tempting to become excited about releasing new features — but it's also crucial to remember that insecure code can harm the business, users, and your team. So, take responsibility for your code's security: avoid older or unmaintained packages, don't introduce untrusted dependencies, and always think before installing.

Security is not simple, but it is your responsibility, and I believe in you. Let's create safer software one commit at a time.

Han Solo: May the force be with you

Here's a GitHub Actions workflow to execute Trivy on any pushed commit:

name: Trivy Scan

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  fs-scan:
    runs-on: ubuntu-latest
    name: Run Trivy Filesystem Scan
    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Run Trivy vulnerability scanner in fs mode
      uses: aquasecurity/trivy-action@master
      with:
        scan-type: 'fs'
        scan-ref: '.'
        trivy-config: trivy/trivy.yaml
        severity: 'HIGH,CRITICAL'
        exit-code: 2

  image-scan:
    runs-on: ubuntu-latest
    name: Run Trivy Image Scan
    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Build Docker image
      run: docker build -f Containerfile -t local-nginx .

    - name: Run Trivy vulnerability scanner in image mode
      uses: aquasecurity/trivy-action@master
      with:
        scan-type: 'image'
        image-ref: 'local-nginx'
        trivy-config: trivy/trivy.yaml
        severity: 'HIGH,CRITICAL'
        exit-code: 2
  
  config-scan:
    runs-on: ubuntu-latest
    name: Run Trivy Config Scan
    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Run Trivy vulnerability scanner in config mode
      uses: aquasecurity/trivy-action@master
      with:
        scan-type: 'config'
        scan-ref: '.'
        trivy-config: trivy/trivy.yaml
        severity: 'HIGH,CRITICAL'
        exit-code: 2

As you can see, I utilized three scanning methods: fs to scan the local file system directory and image to scan a custom container image that was created and made available locally and config to scan IaC.

The Trivy file settings (trivy.yaml):

severity:
  - HIGH
  - CRITICAL

ignore-unfixed: true

ignore:
  vulnerabilities:
    - CVE-2021-12345
    - CVE-2022-67890

output:
  format: table

scan:
  config:
    enabled: true
  secrets:
    enabled: true
  iac:
    enabled: true
    policies:
      - terraform
      - kubernetes

timeout: 5m

severity: Defines the severity levels that your scan will treat as vulnerabilities.
ignore: This section allows you to specify which CVEs to bypass during the scan, but use with caution as it’s at your own risk.
scan: Here, you can choose the type of scans to run, such as scanning Docker images, file systems, or Infrastructure as Code (IaC).

🧪 Output (trimmed)

Here, we have the outputs from Trivy for three different types of scans: container image, file system, and Infrastructure as Code (IaC).

I created files with vulnerabilities to demonstrate Trivy in action. These include insecure IaC, secrets exposed in a file, and a vulnerable container image.

Report Summary

┌─────────────────────────────┬────────┬─────────────────┬─────────┐
│           Target            │  Type  │ Vulnerabilities │ Secrets │
├─────────────────────────────┼────────┼─────────────────┼─────────┤
│ nginx:latest (debian 12.10) │ debian │       154       │    -    │
└─────────────────────────────┴────────┴─────────────────┴─────────┘

Legend:
- '-': Not scanned
- '0': Clean (no security findings detected)


nginx:latest (debian 12.10)

Total: 154 (UNKNOWN: 2, LOW: 99, MEDIUM: 39, HIGH: 12, CRITICAL: 2)


┌────────────────────┬─────────────────────┬──────────┬──────────────┬─────────────────────────┬───────────────┬──────────────────────────────────────────────────────────────┐
│      Library       │    Vulnerability    │ Severity │    Status    │    Installed Version    │ Fixed Version │                            Title                             │
├────────────────────┼─────────────────────┼──────────┼──────────────┼─────────────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ apt                │ CVE-2011-3374       │ LOW      │ affected     │ 2.6.1                   │               │ It was found that apt-key in apt, all versions, do not       │
│                    │                     │          │              │                         │               │ correctly...                                                 │
│                    │                     │          │              │                         │               │ https://avd.aquasec.com/nvd/cve-2011-3374                    │

AVD-AWS-0132 (HIGH): Bucket does not encrypt data with a customer managed key.
═══════════════════════════════════════════════════════════════════
Encryption using AWS keys provides protection for your S3 buckets. To increase control of the encryption and manage factors like rotation use customer managed keys.


See https://avd.aquasec.com/misconfig/avd-aws-0132
───────────────────────────────────────────────────────────────────
 trivy/example.tf:24-31
───────────────────────────────────────────────────────────────────
  24 ┌ resource "aws_s3_bucket" "insecure_bucket" {
  25 │   bucket = "insecure-bucket-example"
  26 │   acl    = "public-read"
  27 │ 
  28 │   versioning {
  29 │     enabled = false
  30 │   }
  31 └ }

AVD-KSV-0014 (HIGH): Container 'vulnerable-container' of Deployment 'vulnerable-deployment' should set 'securityContext.readOnlyRootFilesystem' to true
═══════════════════════════════════════════════════════════════════
An immutable root file system prevents applications from writing to their local disk. This can limit intrusions, as attackers will not be able to tamper with the file system or write foreign executables to disk.

See https://avd.aquasec.com/misconfig/ksv014
───────────────────────────────────────────────────────────────────
 trivy/deployment.yml:18-34
───────────────────────────────────────────────────────────────────
  18 ┌       - name: vulnerable-container
  19 │         image: nginx:1.16
  20 │         ports:
  21 │         - containerPort: 80
  22 │         env:
  23 │         - name: SECRET_KEY
  24 │           value: "hardcoded-secret"
  25 │         securityContext:
  26 └           privileged: true

HIGH: AsymmetricPrivateKey (private-key)
════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Asymmetric Private Key
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 trivy/secrets.txt:10
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   8     "project_id": "fake-project-id",
   9     "private_key_id": "fakeprivatekeyid12345",
  10 [   "private_key": "-----BEGIN PRIVATE KEY-----******************-----END PRIVATE KEY-----\n",
  11     "client_email": "[email protected]",
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Trust me 🤝, you can check the results directly in the GitHub CI:

Best Practices

Frequent scans

Running vulnerability scans on each commit is secure, but it may be costly 💸🤑💰, particularly in businesses with hundreds of developers and several projects. Your CI pipeline may struggle under the pressure, affecting performance and developer productivity.

Instead, consider examining your CI phases and selecting the appropriate time to execute security tests. As your procedures evolve, you can use common, "pre-scanned" base images across projects to reduce scanning time while retaining a high level of security.

Prioritize high and critical vulnerabilities

Make sure your workflow fails when critical or high-severity vulnerabilities are discovered. Detecting vulnerabilities early is critical, but not every vulnerability should halt development. According to your risk tolerance and business environment, low or medium-level vulnerabilities may be acceptable, but don't wait until they reach high levels to pay attention 🧐.

It is critical to determine which severity levels are undesirable in production and which are manageable. This decision should be part of an ongoing, open discussion between 👨‍💻development and 👮security teams to find the correct balance between safety and productivity.

Regular updates

Keeping your base images and dependencies up to date is one of the best strategies to reduce vulnerabilities. Scanning helps you detect worries early on, but it's also critical to understand why those vulnerabilities exist in your stack.

For example, if your application depends on too many libraries, you run the danger of importing deprecated or unmaintained packages. In ecosystems like NPM, a single dependent might pull in dozens of transitive dependencies, sometimes for functionality you rarely use. In such circumstances, consider creating lightweight alternatives or including only what you require.

Be cautious of using trendy frameworks or libraries simply because they're popular. If they stop receiving updates or support from the community, you could be left with a security risk 🧠.

Don't make decisions based solely on emotions ❤️; remember the wisdom of this Bible verse:

Jeremiah 17:9 (NIV):
"The heart is deceitful above all things and beyond cure. Who can understand it?"

While solutions like Trivy promote a culture of regular updates, it is your obligation to ensure that your team avoids unmaintained or obsolete dependencies - prevention begins with smart choices.

Outputs on CI

Depending on your CI volume and team size, reviewing scan results immediately within the CI pipeline might be confusing and hard to read, making it 🥴 challenging for developers to identify and resolve vulnerabilities effectively.

To optimize this process, Trivy reports can be integrated with other tools, such as SonarQube, to improve the user experience, consolidate security issues, and provide more explicit solutions. This integration helps you organize vulnerability data, streamline issue tracking, and enable developers to focus on fixing significant problems rather than becoming lost in a sea of scan results.

Code

💡 Feel free to clone this repository, which contains related files:

GitHub - williampsena/ci-repices: This repository contains useful Github Actions CI recipes

This repository contains useful Github Actions CI recipes - williampsena/ci-repices

GitHubwilliampsena

Conclusion

That’s all for today, folks! I hope you enjoyed this quick dive into Trivy.
My goal was to raise awareness about security and share practical tools and best practices that you can apply in your daily development workflow.

Stay safe, write secure code, never stop learning and keep your kernel 🧠 up to date!

Neo Matrix: Kernel Upgrades

References

]]>

Wed, 09 Apr 2025 17:04:04 GMT

Linguagem	Suporte OpenTelemetry	Estágio
Java	✅ Sim	Estável
JavaScript (Node.js/Browser)	✅ Sim	Estável
Python	✅ Sim	Estável
Go	✅ Sim	Estável
.NET (C#)	✅ Sim	Estável
Ruby	✅ Sim	Estável
C++	✅ Sim	Em evolução
PHP	⚠️ Parcial	Em desenvolvimento
Rust	⚠️ Parcial	Comunidade ativa
Swift	⚠️ Parcial	Projeto comunitário
Erlang/Elixir	⚠️ Parcial	Projeto comunitário

🔎 Observação: As linguagens com suporte “parcial” ou “em desenvolvimento” ainda estão evoluindo ou são mantidas pela comunidade.

Entregando observabilidade

Diagrama do fluxo OpenTelemetry

No diagrama acima, visualizamos as principais camadas de uma arquitetura de observabilidade. Iniciando pela camada das aplicações, que são as responsáveis por gerar os insumos fundamentais: logs, traces e métricas. Em seguida, entra o OpenTelemetry Collector, que atua como intermediário — ele recebe, processa e transforma esses dados, encaminhando-os para um ou mais exporters, que se encarregam de armazená-los ou redirecioná-los para ferramentas especializadas.

Por fim, temos a camada de apresentação, composta por interfaces de visualização (UIs), onde é possível construir dashboards, configurar alertas e executar queries sobre os dados coletados. Neste exemplo, usamos apenas duas ferramentas, mas a arquitetura é flexível e compatível com diversas soluções comerciais amplamente adotadas no mercado, como Datadog, New Relic, Kibana, entre outras.

Se o objetivo for algo mais simples, especialmente em ambientes de desenvolvimento, também é possível enviar os dados diretamente para o Jaeger, que oferece uma visualização prática e eficiente dos três pilares da observabilidade: métricas, logs e traces.

Chega de Teoria, Vamos Codar!

Há algum tempo, iniciei algumas POCs com o objetivo de descomplicar a instrumentação com OpenTelemetry em aplicações escritas nas diversas linguagens que compunham a stack com a qual eu estava trabalhando.

Durante esse processo, acabei mudando de empresa — mas continuei esse estudo, evoluindo a ideia e consolidando o aprendizado em uma apresentação resumida, que agora serve de base para este artigo.

Como mencionei antes, estamos lidando com várias linguagens, então a proposta aqui é mostrar rapidamente trechos de implementação, só pra dar o gostinho. E claro: o repositório com todos os exemplos está disponível — você pode clonar, testar e entender na prática como a instrumentação com OpenTelemetry funciona em cada caso:

GitHub - williampsena/otel-recipes: This repository has a proof-of-concept that uses the Opentelemetry processor to prevent revealing sensitive data.

This repository has a proof-of-concept that uses the Opentelemetry processor to prevent revealing sensitive data. - williampsena/otel-recipes

GitHubwilliampsena

Configurando o OpenTelemetry

A configuração do colector (OTel)

otel-collector-config.yaml

# OpenTelemetry Collector config that receives OTLP
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: "0.0.0.0:4317"
      http:
        endpoint: "0.0.0.0:4318"

processors:
  batch:
    send_batch_size: 1024
    timeout: 5s

  attributes/scrape:
    actions:
      - key: environment
        value: production
        action: insert

      - key: process.command_line
        action: delete
      - pattern: credit_card
        action: delete
      - pattern: password
        action: delete

      - pattern: email
        action: hash
      - pattern: vatnumber
        action: hash
      - pattern: document
        action: hash
      - pattern: x_secret_key
        action: hash

exporters:
  debug:
      verbosity: detailed

  otlp/jaeger:
    endpoint: jaeger:4317
    tls:
      insecure: true

  loki:
    endpoint: http://loki:3100/loki/api/v1/push

  prometheus:
    endpoint: 0.0.0.0:18888

  otlp/tempo:
    endpoint: tempo:4317
    tls:
      insecure: true

extensions:
  zpages: {}

service:
  extensions: [zpages]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [attributes/scrape, batch]
      exporters: [otlp/jaeger, otlp/tempo]
    metrics:
      receivers: [otlp]
      processors: [attributes/scrape, batch]
      exporters: [prometheus]
    logs:
      receivers: [otlp]
      processors: [attributes/scrape, batch]
      exporters: [loki]

Nesta configuração, o OpenTelemetry Collector não se limita apenas à coleta de dados — também configuramos etapas de processamento para demonstrar todo o potencial da ferramenta. O objetivo é mostrar como o coletor pode transformar dados em tempo real, seja inserindo novos campos, removendo informações desnecessárias ou mascarando dados sensíveis para evitar exposições indesejadas.

Abaixo, explicamos os principais blocos da configuração:

receivers: definem os endpoints de entrada por onde o coletor recebe os dados. É aqui que especificamos quais protocolos ou fontes o OpenTelemetry Collector deve escutar.
processors : responsáveis por transformar os dados recebidos. Podemos, por exemplo, remover informações sensíveis, adicionar marcações personalizadas (como tags de ambiente ou origem), ou filtrar dados irrelevantes, garantindo que apenas informações úteis sejam enviadas para os destinos finais.
exporters: definem os destinos para onde os dados de observabilidade serão enviados. Entre as opções mais comuns estão o Jaeger, DataDog, Prometheus, entre outros sistemas de monitoramento e rastreamento.
service: é aqui que configuramos as pipelines de execução para cada um dos pilares da observabilidade — logs, traces e métricas. Cada pipeline determina quais são os seus respectivos receivers, processors e exporters, orquestrando o fluxo completo dos dados dentro do coletor.

Os containers

docker-compose.yml

name: otel

services:  
  otel:
    profiles: [all, otel]
    networks:
      - otel
    ports:
      - 14317:4317
      - 14318:4318
      - 18888:18888
    image: otel/opentelemetry-collector-contrib:0.123.0
    command: ["--config=/conf/otel-collector-config.yaml"]
    privileged: true
    volumes:
      - "./otel/otel-collector-config.yaml:/conf/otel-collector-config.yaml"
    depends_on:
      - loki

  jaeger:
    profiles: [all, otel]
    networks:
      - otel
    image: jaegertracing/all-in-one:1.68.0
    ports:
      - 16687:16686
    depends_on:
      - otel

  prometheus:
    profiles: [all, otel]
    networks:
      - otel
    image: prom/prometheus:v3.2.1
    ports:
      - "9090:9090"
    volumes:
      - prometheus-data:/prometheus
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml

  grafana:
    profiles: [all, grafana]
    networks:
      - otel
    image: grafana/grafana:11.6.0
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - grafana-data:/var/lib/grafana
    depends_on:
      - loki
      - tempo

  loki:
    profiles: [all, grafana]
    networks:
      - otel
    image: grafana/loki:3
    command: [ "-config.file=/etc/loki/local-config.yaml" ]
    ports:
      - "3100:3100"
    volumes:
      - ./grafana/loki-config.yaml:/etc/loki/local-config.yaml
      - loki-rules-data:/etc/loki/rules/fake

  promtail:
    profiles: [all, grafana]
    networks:
      - otel
    image: grafana/promtail:3
    volumes:
      - ./grafana/promtail-config.yaml:/etc/promtail/config.yml
      - /var/log:/var/log
      - /var/lib/docker/containers:/var/lib/docker/containers
    depends_on:
      - loki
      - prometheus

  tempo:
    profiles: [all, grafana]
    networks:
      - otel
    image: grafana/tempo:latest
    command: [ "-config.file=/etc/tempo/tempo.yaml" ]
    ports:
      - "3200:3200"
    volumes:
      - ./grafana/tempo-config.yaml:/etc/tempo/tempo.yaml
      - tempo-data:/var/tempo

  redis:
    profiles: [all, db]
    networks:
      - otel
    image: bitnami/redis:7.2
    environment:
      - ALLOW_EMPTY_PASSWORD=yes
    ports:
      - 6379:6379

  python:
    profiles: [all, apps]
    networks:
      - otel
    build:
      dockerfile: ./app/python/Containerfile
    environment:
      - PORT=8000
      - OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED=true
      - OTEL_EXPORTER_OTLP_ENDPOINT=http://otel:4317
      - OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://otel:4317/v1/traces
      - OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://otel:4317/v1/metrics
      - OTEL_RESOURCE_ATTRIBUTES="service.name=python-otlp,team=dev,cluster-name=local,env=dev"
      - OTEL_SERVICE_NAME=python-otlp
    ports:
      - 8000:8000
    depends_on:
      - otel

  go:
    profiles: [all, apps]
    networks:
      - otel
    build:
      dockerfile: ./app/go/Containerfile
    environment:
      - OTEL_EXPORTER_OTLP_ENDPOINT=http://otel:4317
      - OTEL_RESOURCE_ATTRIBUTES="service.name=go-otlp,team=dev,cluster-name=local,env=dev"
      - OTEL_SERVICE_NAME=go-otlp
      - REDIS_URL=redis:6379
    ports:
      - 8001:8001
    depends_on:
      - otel

  ruby:
    profiles: [all, apps]
    networks:
      - otel
    build:
      dockerfile: ./app/ruby/Containerfile
    environment:
      - PORT=8002
      - OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://otel:4318/v1/traces
      - OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://otel:4318/v1/metrics
      - OTEL_RESOURCE_ATTRIBUTES="service.name=ruby-otlp,team=dev,cluster-name=local,env=dev"
      - OTEL_SERVICE_NAME=ruby-otlp
      - OTEL_TRACES_EXPORTER=otlp
    ports:
      - 8002:8002
    depends_on:
      - otel

  node:
    profiles: [all, apps]
    networks:
      - otel
    build:
      dockerfile: ./app/node/Containerfile
    environment:
      - PORT=8003
      - OTEL_EXPORTER_OTLP_ENDPOINT=http://otel:4318
      - OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://otel:4318/v1/traces
      - OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://otel:4318/v1/metrics
      - OTEL_RESOURCE_ATTRIBUTES="service.name=node-otlp,team=dev,cluster-name=local,env=dev"
      - OTEL_SERVICE_NAME=node-otlp
      - OTEL_TRACES_EXPORTER=otlp
    ports:
      - 8003:8003
    depends_on:
      - otel

volumes:
  tempo-data:
  loki-rules-data:
  grafana-data:
  prometheus-data:

networks:
  otel:
    name: "otel"

Otel: Abreviação de OpenTelemetry Collector, é o componente responsável por receber, processar e exportar dados de observabilidade como logs, métricas e traces.
Jaeger: Ferramenta de distributed tracing que permite rastrear o caminho completo de uma requisição em sistemas distribuídos, sendo muito útil em arquiteturas de microserviços para identificar gargalos e monitorar a performance entre serviços.
Prometheus: Solução de monitoramento que coleta e armazena métricas em tempo real. Possui suporte a consultas avançadas e permite a criação de alertas e dashboards personalizados.
Grafana: Plataforma web de código aberto para visualização e análise de dados. Suporta múltiplas fontes, como Prometheus, Loki e Tempo, e é amplamente utilizada para criação de dashboards interativos.
Loki: Sistema de gerenciamento de logs desenvolvido pela Grafana Labs. Ao contrário de outras soluções, como o Elasticsearch, o Loki é otimizado para trabalhar em conjunto com Prometheus e Grafana, utilizando os mesmos rótulos (labels) e focando em logs estruturados e de fácil correlação com métricas e traces.
Promtail: Agente responsável por coletar logs de arquivos locais e enviá-los ao Loki, o sistema de gerenciamento de logs da Grafana.
Tempo: Plataforma open-source mantida pela Grafana Labs, voltada para o gerenciamento de distributed tracing. Permite a correlação de traces com métricas e logs em um único ambiente visual.
Redis: Sistema de cache em memória amplamente utilizado por aplicações. Pensando em testes do contexto de observabilidade, pode gerar spans de traces relacionados a operações de leitura e escrita no cache.
Python, Ruby, Go e Node: Exemplos de containers de aplicação que atuam como fontes de dados para o coletor OpenTelemetry, fornecendo logs, métricas e traces que alimentam todo o pipeline de observabilidade.

Os arquivos de configuração do Loki, Tempo e Promtail estão disponíveis no repositório e devem ser baixados antes da execução. Eles garantem que cada serviço funcione corretamente dentro do pipeline de observabilidade.

Instrumentação

No repositório, você encontrará diversos exemplos de instrumentação. Neste artigo, vamos focar brevemente na implementação em Go. Por ser uma linguagem compilada, o Go exige uma abordagem mais explícita e detalhada na instrumentação. Já em linguagens interpretadas como Node.js, Ruby e Python, esse processo tende a ser mais simples, graças aos recursos de metaprogramação que facilitam a inserção automática de telemetria no código.

Go

package main

import (
	"context"
	"encoding/json"
	"fmt"
	"log"
	"os"

	"net/http"

	"github.com/brianvoe/gofakeit/v7"
	"github.com/prometheus/client_golang/prometheus"
	"github.com/prometheus/client_golang/prometheus/promauto"
	"github.com/prometheus/client_golang/prometheus/promhttp"
	"github.com/redis/go-redis/extra/redisotel/v9"
	"github.com/redis/go-redis/v9"
	"go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp"
	"go.opentelemetry.io/otel"
	"go.opentelemetry.io/otel/attribute"
	"go.opentelemetry.io/otel/exporters/otlp/otlptrace"
	"go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"
	"go.opentelemetry.io/otel/sdk/resource"
	sdktrace "go.opentelemetry.io/otel/sdk/trace"
	"go.opentelemetry.io/otel/trace"
)

// Email counter metric
var emailCounter = promauto.NewCounter(prometheus.CounterOpts{
	Name: "email_counter",
	Help: "The total number of email sent",
})

// Shutdown handler is responsible for finishing trace.
type ShutdownHandler func(context.Context) error

// Regular email data
type Email struct {
	From    string `json:"from"`
	To      string `json:"to"`
	Subject string `json:"subject"`
	Body    string `json:"body"`
}

// Regular customer
type Customer struct {
	Id       string // the customer unique id
	Name     string // the customer name
	Document string // the document number
	Email    string // the customer email
}

// This function is responsible for setting up the program before it runs
func init() {
	gofakeit.Seed(0)
}

// Build redis client connection
func setupRedis() *redis.Client {
	rdb := redis.NewClient(&redis.Options{
		Addr:     os.Getenv("REDIS_URL"),
		Password: "",
		DB:       0,
	})

	if err := redisotel.InstrumentTracing(rdb); err != nil {
		panic(err)
	}

	if err := redisotel.InstrumentMetrics(rdb); err != nil {
		panic(err)
	}

	return rdb
}

// Initializes the open telemetry tracer.
func setupTracer(ctx context.Context) (ShutdownHandler, error) {
	exporter, err := otlptracegrpc.New(ctx)
	if err != nil {
		return nil, err
	}

	tp := buildTracer(ctx, exporter)

	otel.SetTracerProvider(tp)

	return tp.Shutdown, nil
}

// Build an open telemetry tracer
func buildTracer(ctx context.Context, exporter *otlptrace.Exporter) *sdktrace.TracerProvider {
	res, err := resource.New(ctx,
		resource.WithAttributes(
			attribute.String("service.name", os.Getenv("OTEL_SERVICE_NAME")),
		),
	)

	if err != nil {
		panic(err)
	}

	return sdktrace.NewTracerProvider(
		sdktrace.WithBatcher(exporter),
		sdktrace.WithResource(res),
	)
}

// Responsible for finalizing trace context.
func doShutdown(ctx context.Context, shutdown ShutdownHandler) {
	func() {
		if err := shutdown(ctx); err != nil {
			log.Fatalf("failed to shut down tracer: %v", err)
		}
	}()

}

// Add span attributes values
func setupSpanValues(span trace.Span) {
	span.SetAttributes(
		attribute.String("customer.id", gofakeit.UUID()),
		attribute.String("customer.email", gofakeit.Email()),
		attribute.String("customer.password", gofakeit.Password(true, true, true, true, true, 10)),
		attribute.String("customer.vatnumber", gofakeit.SSN()),
		attribute.String("customer.credit_card", gofakeit.CreditCard().Number),
		attribute.String("db.user", gofakeit.Username()),
		attribute.String("db.password", gofakeit.Password(true, true, true, true, true, 10)),
		attribute.String("account.email", gofakeit.Email()),
	)
}

// Returns an internal server error
func writeHttpError(span trace.Span, w http.ResponseWriter, errorMessage string) {
	span.AddEvent("error",
		trace.WithAttributes(
			attribute.String("value", errorMessage),
		),
	)
	span.End()

	w.WriteHeader(http.StatusInternalServerError)
	w.Write([]byte(errorMessage))
}

// Route to generate stats for every request.
func sendEmailRoute(rdb *redis.Client) func(w http.ResponseWriter, r *http.Request) {
	return func(w http.ResponseWriter, r *http.Request) {
		tracer := otel.Tracer("go-tracer")
		_, span := tracer.Start(r.Context(), "send-email")

		message, err := gofakeit.EmailText(&gofakeit.EmailOptions{})

		if err != nil {
			writeHttpError(span, w, fmt.Sprintf("failed to fetch random message: %v", err))
			return
		}

		customer := Customer{
			Id:       gofakeit.UUID(),
			Name:     gofakeit.Name(),
			Email:    gofakeit.Email(),
			Document: gofakeit.SSN(),
		}

		email := Email{
			From:    fmt.Sprintf("no-reply@%v", gofakeit.DomainName()),
			To:      customer.Email,
			Subject: gofakeit.BookTitle(),
			Body:    message,
		}

		span.SetAttributes(
			attribute.String("customer.id", customer.Id),
			attribute.String("customer.email", customer.Email),
			attribute.String("customer.document", customer.Document),
		)

		setupSpanValues(span)

		jsonEmail, err := json.Marshal(email)

		if err != nil {
			writeHttpError(span, w, fmt.Sprintf("failed to parse email message: %v", err))
			return
		}

		err = rdb.SPublish(r.Context(), "email", jsonEmail).Err()

		if err != nil {
			writeHttpError(span, w, fmt.Sprintf("failed to queue email message: %v", err))
			return
		}

		span.AddEvent("email",
			trace.WithAttributes(
				attribute.String("subject", email.Subject),
				attribute.String("content", email.Body),
			),
		)

		emailCounter.Inc()

		response := fmt.Sprintf("📨 The email was queued successfully: %v", email.Subject)

		span.AddEvent("log-message", trace.WithAttributes(attribute.String("message", message)))

		log.Println(message)

		span.End()

		w.WriteHeader(http.StatusCreated)
		w.Write([]byte(response))
	}
}

func main() {
	rdb := setupRedis()
	ctx := context.Background()
	shutdown, err := setupTracer(ctx)

	if err != nil {
		log.Fatalf("failed to initialize open telemetry tracer: %v", err)
	}

	defer doShutdown(ctx, shutdown)

	otelHandler := otelhttp.NewHandler(http.HandlerFunc(sendEmailRoute(rdb)), "SendEmail")

	http.Handle("/metrics", promhttp.Handler())
	http.Handle("/send-email", otelHandler)

	http.ListenAndServe(":8001", nil)
}

Abaixo temos a implementação de uma métrica do tipo contador, responsável por registrar o total de e-mails enviados. Esse tipo de dado pode ser utilizado para gerar gráficos, indicar o funcionamento da aplicação e até mesmo disparar alertas em situações anômalas.

No caso específico da aplicação escrita em Go, optei por utilizar o Prometheus para expor as métricas em vez do próprio OpenTelemetry. Isso porque, durante os testes, apenas a aplicação em Go apresentou dificuldades ao despachar métricas diretamente via OTel.

Felizmente, o Prometheus é totalmente compatível com o OpenTelemetry Collector, o que nos permite integrá-lo de forma transparente ao pipeline de observabilidade.

var emailCounter = promauto.NewCounter(prometheus.CounterOpts{
	Name: "email_counter",
	Help: "The total number of email sent",
})

http.Handle("/metrics", promhttp.Handler())

http.ListenAndServe(":8001", nil)

Aqui estamos enviando por meio do tracer um span (send-email), que representa uma ação ou operação dentro do sistema. Esse rastro pode ser visualizado nas ferramentas de observabilidade para ajudar a entender o comportamento da aplicação em tempo real.

tracer := otel.Tracer("go-tracer")
_, span := tracer.Start(r.Context(), "send-email")

A integração de logs no Go funciona principalmente através de Events adicionados aos spans. No entanto, a integração direta com loggers ainda precisa ser melhor explorada.

Como o ⚠️ SDK do OpenTelemetry para Go ainda está em desenvolvimento ativo, algumas dessas funcionalidades não estão totalmente integradas ou exigem soluções manuais.

span.AddEvent("email",
    trace.WithAttributes(
        attribute.String("subject", email.Subject),
        attribute.String("content", email.Body),
    ),
)

span.AddEvent("error",
    trace.WithAttributes(
        attribute.String("value", errorMessage),
    ),
)

span.End()

Outras instrumentações, como mencionamos anteriormente, são mais simples de configurar. Você pode conferir os detalhes e exemplos completos diretamente no repositório no GitHub.

Como testar?

Preparei um script em Bash (scripts/do-requests.sh) que será responsável por executar múltiplas requisições nas aplicações, com o objetivo de gerar logs, métricas e traces que alimentarão nosso pipeline de observabilidade.

Antes de executar o script, é importante garantir que todos os containers estejam em funcionamento. Para isso, utilize o seguinte comando:

docker compose --profile all up -d

Esse comando irá iniciar todos os serviços definidos no docker-compose.yml em segundo plano. Assim que os containers estiverem ativos, podemos prosseguir com a execução do script de carga para simular o comportamento das aplicações.

Com todos os containers em execução, estamos prontos para gerar os insumos de observabilidade — ou seja, os logs, métricas e traces que serão processados pelo nosso coletor.

Execute o comando abaixo para iniciar o script de carga:

bash scripts/do-requests.sh

Execução do script para requests

Após a execução, já teremos dados disponíveis para visualização direta no Grafana e no Jaeger, que foram definidos como nossos exporters.

Grafana

Grafana UI

O Grafana tem como foco oferecer uma experiência completa em observabilidade. Além de visualizar logs, traces e métricas, ele permite criar dashboards personalizadas e configurar alertas inteligentes, proporcionando uma visão centralizada e em tempo real do comportamento dos sistemas.

No detalhe 🔍

Logs integrados por meio do Grafana Loki

Traces integrados por meio do Grafana Tempo

Visualização das métricas coletadas com Prometheus integrado ao OpenTelemetry. Algumas métricas são expostas diretamente pelo Prometheus, enquanto outras são enriquecidas e encaminhadas pelo OpenTelemetry Collector.

Jaeger

Com o Jaeger, é possível observar traces, métricas e logs de forma minimalista e objetiva. Ele é extremamente útil para identificar gargalos e entender o fluxo de requisições dentro da aplicação, especialmente em ambientes com microsserviços. Além disso, o Jaeger permite importar traces em formato JSON, facilitando análises manuais ou integrações com outras ferramentas.

No detalhe 🔍

Conclusão

Neste artigo, criamos um exemplo prático de integração de aplicações em diferentes linguagens com o OpenTelemetry. Exploramos as principais configurações do repositório e vimos como os dados de observabilidade são exibidos no Jaeger e no Grafana.

Espero que essa introdução ao OpenTelemetry ajude a aumentar a visibilidade dos seus projetos e torne sua vida de desenvolvedor mais tranquila — e com menos emoções indesejadas.

E por hoje é isso!

Que Deus 🕊️ te abençoe, e não se esqueça: mantenha seu kernel 🧠 sempre atualizado!

]]>

Sat, 29 Mar 2025 21:05:00 GMT

O que é?

Há algum tempo, os repositórios deixaram de ser apenas depósitos de código e assumiram a função de centralizar a documentação, o fluxo de testes e a publicação em produção, entre outras obrigações. Com todas essas obrigações, também temos a responsabilidade de proteger valores importantes do nosso repositório, como a senha do banco de dados, a chave de autenticação e até mesmo a chave usada apenas para staging, que pode parecer inofensiva. 🐱 🦁

Essa não é uma prática recomendada, conforme mencionado em 12 Fatores, onde se enfatiza que as configurações devem ser mantidas em variáveis de ambiente e que uma aplicação deve ser projetada para funcionar em qualquer ambiente. No entanto, reconhecemos que, sem uma verificação periódica, pode ocorrer um vazamento não intencional. Subimos aquele arquivo com alguma referência de produção relevante ou não. Às vezes, isso acontece de maneira proposital 🥺, pois é mais fácil e rápido subir aquela variável diretamente em um arquivo de configuração ou Containerfile 🐳.

Como podemos prevenir?

Este artigo serve como uma iniciativa para a prevenção de segredos em repositórios, estruturando um projeto desde o inicio para prevenir falhas básicas de segurança. Lamentavelmente, vivemos em um mundo onde qualquer falha pode resultar em danos para indivíduos ou empresas, proporcionando lucro fácil para criminosos 🥷🏻💸🤑💰.

O Gitleaks é uma solução viável e de código aberto ❤️ que permite detectar vazamentos em nossos repositórios git.

Como funciona?

O Gitleaks é uma ferramenta que a cada execução avalia a nível de diretório ou de histórico com base no git, verificando se existem vazamentos no repositório, estas duas formas são importantes, e podemos utilizar da seguinte forma.

Novas alterações podem ser analisadas no nível do repositório, onde podemos determinar se um novo código violou alguma regra ou se houve vazamento de dados.
Ao realizar a varredura por pipeline, é aconselhável analisar o repositório e seu histórico, pois as regras podem ser atualizadas e um novo vazamento pode ser detectado, ou durante a implementação do gitleaks, podem ser detectados apontamentos baseados no histórico.

Bora ☕ !

.gitleaks.toml

Primeiramente, crie um arquivo chamado .gitleaks.toml, onde adicionaremos as regras do nosso scan gitleaks. É comum termos falsos positivos, por isso, a ferramenta oferece métodos para ignorar arquivos ou "matches" que possam provocar essa situação.

Aqui um exemplo:

[extend]
useDefault = true

[allowlist]
description = "global allow list"
paths = [
  '''gitleaks\.toml''',
  '''gitleaks-report\.json''',
  '''\.env$''',
  '''(.*?)(jpg|gif|doc)''',
]

[[rules]]
id="aws-access-key"
description = "AWS Access Key"
regex = '''AKIA[0-9A-Z]{16}'''
tags = ["key", "AWS"]

[[rules]]
id="aws-access-secret"
description = "AWS Secret Key"
regex = '''(?i)aws_secret_access_key\s*=\s*[A-Za-z0-9/+=]{40}'''
tags = ["key", "AWS"]

extend, indica que é uma extensão da configuração padrão.
allowlist, a lista de permissões estabelece regras permissivas, como, por exemplo os arquivos que não devem ser levados em conta no escaneamento.
rules, é possível estabelecer várias regras para detecção de vazamento de dados sensíveis.

Pronto, esta foi uma abordagem sucinta à configuração, onde podemos encontrar exemplos mais detalhados diretamente na documentação do Gitleaks, na seção "Configurações".

Arquivo com dados sensíveis

.env.sample

MY_WEAK_PASSWORD=X
MY_STRONG_PASSWORD=QJJ0S81ogYX5iJebUM4LN1FOFFuQKo0B
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Executando em um diretório

Com a configuração concluída e um arquivo sensível em mãos, podemos iniciar o escaneamento.

docker run --rm -v $(pwd):/repo \
    zricethezav/gitleaks:latest \
    dir /repo \
    --gitleaks-ignore-path .gitleaksignore \
    --config /repo/.gitleaks.toml \
    --report-format json \
    --report-path /repo/gitleaks-report.json \
    -v

O resultado esperado deve identificar vazamentos.

Finding:     MY_STRONG_PASSWORD=QJJ0S81ogYX5iJebUM4LN1FOFFuQKo0B
Secret:      QJJ0S81ogYX5iJebUM4LN1FOFFuQKo0B
RuleID:      generic-api-key
Entropy:     4.452819
File:        /repo/.env.sample
Line:        2
Fingerprint: /repo/.env.sample:generic-api-key:2

12:03PM INF scan completed in 2.19ms
12:03PM WRN leaks found: 3

Executando em um repositório git

Anteriormente, utilizamos o modo diretório, que não leva em conta os históricos do git. O comando a seguir examina todo o histórico do repositório. Não aconselho a execução deste em um pre-commit devido à performance e desnecessário analisar o histórico a cada alteração. Este procedimento é apropriado para um pipeline de execução.

docker run --rm -v $(pwd):/repo \
    zricethezav/gitleaks:latest \
    detect --source /repo \
    --config /repo/.gitleaks.toml \
    --report-format json \
    --report-path /repo/gitleaks-report.json \
    -v

Como corrigir?

É necessário determinar se o vazamento é significativo. Se for, ele deve ser removido do repositório. Se for detectado é aconselhável redefinir a senha ou a chave. Podemos também realizar reflog, rebase no repositório para eliminar completamente o vazamento. Também podemos usar o .gitleaksignore para ignorar commits ou até mesmo ignorar dados não sensíveis que foram detectados no escaneamento.

Neste cenário, presumimos que este apontamento já foi enviado ao repositório anteriormente e desejamos ignorar o mesmo. Para isso crie um arquivo chamado .gitleaksignore.

SEU_COMMIT_HASH_AQUI:.env.sample:generic-api-key:2

Extras

Make

Adotei essa prática em meus projetos há algum tempo, uma herança do que aprendi em Golang 🦫. O Makefile é um arquivo utilizado por um utilitário chamado make, um instrumento de automação de compilação e gestão de dependências, amplamente utilizado em projetos de software, particularmente em linguagens como C e C++. Além disso, pode ser aplicado em outras tarefas de automação. Se precisamos executar comandos shell, o Makefile nos ajuda a organizar e centralizar a execução dos nossos scripts.

# Define the shell for the make process
SHELL := /bin/bash

REPO_PATH := $(PWD)
GITLEAKS_IMAGE := zricethezav/gitleaks:latest
GITLEAKS_CONFIG := $(REPO_PATH)/.gitleaks.toml
GITLEAKS_REPORT := $(REPO_PATH)/gitleaks-report.json

pre-commit: leaks

leaks-history:
	docker run --rm \
    -v $(REPO_PATH):/repo \
    $(GITLEAKS_IMAGE) \
    detect --source /repo \
    --config /repo/.gitleaks.toml \
    --report-format json \
    --report-path /repo/gitleaks-report.json \
    -v

leaks:
	docker run --rm \
    -v $(REPO_PATH):/repo \
    $(GITLEAKS_IMAGE) \
    dir /repo \
    --config /repo/.gitleaks.toml \
    -v

leaks-report:
	docker run --rm \
    -v $(REPO_PATH):/repo \
    $(GITLEAKS_IMAGE) \
    dir /repo \
    --config /repo/.gitleaks.toml \
    --report-format json \
    --report-path /repo/gitleaks-report.json \
    -v

help:
	@echo "Makefile Commands:"
	@echo "  pre-commit        Run gitleaks-history check before commit"
	@echo "  leaks-history    Run gitleaks history detection on the repository"
	@echo "  leaks            Run gitleaks detection on the repository directory"
	@echo "  leaks-report     Run gitleaks with a report on the repository directory"
	@echo "  help             Show this help message"

%:
	@echo "Unknown target '$@'. Use 'make help' to see available commands."
	@$(MAKE) help

```

Github Actions

O Gitleaks tem um action oficial gratuito para projetos. Projetos abertos não necessitam de registro para utilizar o pipeline, enquanto empresas necessitam desse registro. Somente o uso do pipeline otimizado requer registro, no entanto, o projeto é de código aberto e você pode executar suas ações através do docker diretamente em uma Action, bem como localmente, se necessário.

Segue um exemplo de Github Actions utilizando o padrão disponibilizado pelo Gitleaks:

name: Gitleaks Scan
run-name: Gitleaks Scan in [${{ github.ref_name }}] @${{ github.actor }}

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  gitleaks:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }} 
          args: detect --report-format json --report-path gitleaks-report.json

      - name: Upload Gitleaks report
        uses: actions/upload-artifact@v3
        with:
          name: gitleaks-report
          path: gitleaks-report.json

Pre-commit

Prevenir vazamentos é crucial, portanto, um hook pre-commit auxilia na identificação de vazamentos antes da alteração chegar ao repositório a cada "commit".

pre-commit

#!/bin/sh

make pre-commit

RESULT=$?

if [ $RESULT -ne 0 ]; then
  echo "Pre-commit checks failed. Commit aborted."
  exit 1
fi

exit 0

O comando a seguir estabelece um gatilho que permite a realização de uma varredura a cada atualização de código, conhecida como "commit".

ln -sf $(pwd)/pre-commit $(pwd)/.git/hooks/pre-commit

Repositório

Como sempre, a implementação está no meu repositório do Github, que você pode baixar e testar com o Gitleaks. Para mais informações, consulte o README do projeto.

GitHub - williampsena/gitleaks-recipes: This repository provides examples of using Gitleaks.

This repository provides examples of using Gitleaks. - williampsena/gitleaks-recipes

GitHubwilliampsena

E isso é tudo pessoal!

No repositório você pode validar a execução dos Github Actions e entender um pouco mais na prática como tornar seu código seguro. Espero que tenha entregue o meu tesouro e que esta ajuda tenha sido útil e edificadora, mantendo seu kernel 🧠 atualizado!

Mateus 6:21-23 Pois, onde estiver o seu tesouro, ali também estará o seu coração. ― Os olhos são a lâmpada do corpo. Portanto, se os seus olhos forem bons, todo o seu corpo estará cheio de luz. Mas, se os seus olhos forem maus, todo o seu corpo estará cheio de trevas. Portanto, se a luz que está dentro de você são trevas, quão grandes trevas são!

Referências

]]>

Wed, 03 Jul 2024 23:57:50 GMT

The old and new legacy systems

When we think about legacy systems, we typically think of systems developed in languages like Cobol, Clipper, Pascal, Delphi, Visual Basic, connected to old databases such as Paradox, DB2 and, Firebird.

Nowadays, it's a little different in an organization with multiple languages and projects. For example, Paypal opted to go from Java to Node years ago, and Twitter switched from Ruby to Java. With these examples, we can see that in the legacy context, we are dealing with modern languages, such as Ruby and Java. However, I don't think these developers were driven to change because they favored one language over another.

Refactoring as the solution?

Refactoring is becoming more popular for a particular group of engineers who prefer the hype language over others. I'm not here to pass judgment because I'm wearing this cover 🧙🏾 at a specific point in my career. But I should emphasize that refactoring is never the easiest or best way to solve an issue. As a developer that works with a range of programming languages, You will never find a bulletproof language that works so well for frontend and backend or bff (backend for frontend), that is amazing for mobile, that is lovely and comprehensible for concurrency, that is conformable to test, and so on...

Stop thinking about frameworks and start thinking about how this language will work in your project and ask some questions; the learning curve is good for other members; and consider how other people will solve issues with your produced project. Because if you don't care, you're creating the next legacy system.

Let's get started on a list for creating a stunning legacy system.

1) Languages with limited library support

Before deciding a programming language, evaluate what you plan to develop as a project first, and then whether your stack will be supported by the programming language, for example:

I'd like to create a project involving machine learning or data science. Python, as you may know, is widely used for these reasons and has strong commercial and community support. We may be able to find additional Java or Node libraries, but you will almost certainly have to get your hands dirty translating library behaviors and providing some compatibility.

I'm not arguing that it's completely wrong to use language A or B; you can chose, but you should consider the advantages and downsides. And this decision is sound in the long run when your team chooses to move to another language since there is no support for building quickly, because nowadays you must release fast or your solution design may become deprecated.

2) Use a framework that updates slowly

Nowadays, languages support a wide range of databases, services, and integrations, but occasionally there is limited support, or the community does not generate active updates based on your requirements. That condition is common, for example: NPM, RubyGems and Hex packages without updates for months or years.

Some projects are mature and there is no requirement to update them so frequently, but there comes a specific point when the project is supported by three core committers, each of whom has their own priorities. So, in that case, you must work with these dependencies and collaborate on open-source projects to solve issues or improve security; so, before establishing a framework, list the dependencies as clearly as possible.

Therefore, if open-source efforts exceed commercial efforts, your team may switch from one framework or language to another, introducing legacy systems.

3) Don't think about concurrency or performance.

We commonly hear monolith first and keep it simple, which is a genuine and reliable technique for launching your MVP as soon as possible, but be careful to maintain things simple enough to level up when necessary. I'm not advocating putting reuse ahead of usage, but don't make things too dependent on a framework. Some abstractions with low utilization will allow you to upgrade when "concurrency" comes knocking at your door demand for more performance.

The "performance" is at the door.

4) Avoid writing tests or maintaining adequate coverage.

Coverage tests are a sensitive topic; I've heard that quantity isn't necessarily better than quality, but less coverage is always worse. You should not write code that lacks appropriate coverage; instead, you should enumerate possible cases to provide coverage; that is every developer's duty. Assume you are a developer for an airline system; is less coverage acceptable? Okay, I took it seriously. But if we get a system with no testing and a bad design we should replace it as quickly as possible.

However, these systems will occasionally live a long time if they work properly and don't interfere with the strong performance of the stack, and the team has no plans to touch these poorly built systems. A system without testing is a good approach to start a legacy system, in my opinion.

5) Write in a new language in the same way you do in previous languages.

It is important to note that approaches and patterns can be used to any language, but you should be aware of the two paradigms commonly used when developing a project, the most well-known of which is Object-Oriented Programming (OOP), and another strong paradigm known as Functional Programming (FP). While OOP emphasizes class management and reusing behaviors, FP tackles modules, functions, and immutability, thus comparing different approaches. I propose using a well-known project's design as a guide when developing your project in a new language, because it's common and comprehensible to write code for a language and then have another person look at it and remark...

This code appears to be in another language...

To summarize, writing code in a new language is challenging, especially when establishing a new project, but it is a worthwhile experience. If you did your homework and chose this challenge, try to develop small initiatives first; it's not time to rewrite all behaviors that you consider legacy.

Remember that your baby system could become legacy at the same rate that a npm package is released. 😆

6) Write code for yourself rather than for your team.

I believe this happens more frequently than it should. We should not think of of code as abstract art because abstract art is about feelings and is hard to comprehend. Don't let hype influence how you construct your application; the coding should be as straightforward as history.

When coding, try to use well-known and rock-solid methodologies such as SOLID. If you develop a project for yourself, someone will look at it months or years later and say it's too complex, and it's time to retire it and...

A new legacy was born. To replace the legacy system features, a new system will be released.

Final thoughts

In this article, I discuss things to think about while developing a new system with new behaviors or refactoring behaviors from an existing production system. Sometimes a new system is successful, as proved by metrics and team, but other times a redesign works well for a brief amount of time and a new design is required.

To recap, I am not arguing that we should not test hype languages or frameworks, but rather that when you want to bring these new techniques to your team, you should do your homework, ask questions, create proof of concept (PoC), and test metrics to avoid replacing one issue with another.

Thank you for investing your time in reading; God 🕊️ be with you and keep your kernel 🧠 updated, bye.

]]>

Tue, 28 Nov 2023 09:37:50 GMT

Table of Contents

Why Container Security Matter?

What is Trivy?

⚡ Fast scanning.

🧩 Simple to use.

🔐 Comprehensive Scanning Capabilities

🔄 Shift Left Friendly

📦 Example Use Cases

Setting Up Trivy in GitHub Actions

🧪 Output (trimmed)

Best Practices

Frequent scans

Prioritize high and critical vulnerabilities

Regular updates

Outputs on CI

Code

Conclusion

References

Entregando observabilidade

Chega de Teoria, Vamos Codar!

Configurando o OpenTelemetry

A configuração do colector (OTel)

Os containers

Instrumentação

Go

Como testar?

Grafana

No detalhe 🔍

Jaeger

No detalhe 🔍

Conclusão

Como podemos prevenir?

Como funciona?

Bora ☕ !

.gitleaks.toml

Arquivo com dados sensíveis

.env.sample

Executando em um diretório

Executando em um repositório git

Como corrigir?

Extras

Make

Github Actions

Pre-commit

Repositório

E isso é tudo pessoal!

Referências

Refactoring as the solution?

Let's get started on a list for creating a stunning legacy system.

1) Languages with limited library support

2) Use a framework that updates slowly

3) Don't think about concurrency or performance.

4) Avoid writing tests or maintaining adequate coverage.

5) Write in a new language in the same way you do in previous languages.

6) Write code for yourself rather than for your team.

Final thoughts