Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 43,137
    • Issues 43,137
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,364
    • Merge requests 1,364
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

GitLab 15.0 has launched! Please visit Breaking changes in 15.0 and 15.0 Removals to see which breaking changes may impact your workflow.

  • GitLab.org
  • GitLabGitLab
  • Issues
  • #10880
Closed
Open
Created Apr 03, 2019 by Victor Zagorodny@vzagorodnyContributor30 of 30 tasks completed30/30 tasks

Standardize Security Analyzers Logging

Problem to solve

There is a lack of control over logging and a lack of convention for our Security Analyzers.

Intended users

Persona: Software developer

Tasks

gitlab-org/security-products/analyzers/common!73 (merged) has an example of how to use the common logrus format.

  • Document SECURE_LOG_LEVEL in GitLab docs.

    • https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html
    • https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html
    • https://docs.gitlab.com/ee/user/application_security/sast/index.html
    • https://docs.gitlab.com/ee/user/application_security/secret_detection/index.html
  • Update https://docs.gitlab.com/ee/development/integrations/secure.html to mention how to use logrus / common logrus format.

  • Replace fmt print and log calls with the appropriate logrus calls in common.

  • Add support for the SECURE_LOG_LEVEL env var in common.

  • (Static Analysis) replace fmt print and log calls with the appropriate logrus calls in:

    • bandit
    • brakeman
    • eslint
    • flawfinder
    • gosec
    • kubesec
    • nodejs-scan
    • phpcs-security-audit
    • pmd-apex
    • secrets
    • security-code-scan
    • sobelow
    • spotbugs
    • tslint
  • (Dependency Scanning) replace fmt print and log calls with the appropriate logrus calls in:

    • bundler-audit
    • gemnasium-maven
    • gemnasium-python
    • gemnasium
    • retire.js
  • Update klar to use the common logutil for setting the formatter

What does success look like, and how can we measure that?

  • All output is configurable via logrus
  • fmt is no longer used to output messages
  • There is a convention documented for the developer of Security Products and it's executed for any new Security Product project created

What is the type of buyer?

  • GitLab Ultimate users
  • users of the Security Products in their standalone form (as Docker images)

Links / references

Started as a side-talk within #9592 (closed)

Edited Jul 07, 2020 by Daniel Paul Searles
Assignee
Assign to
Time tracking