This is the release branch for YOCTO sumo.

As this layer ran out of support by YOCTO, don't expect regular updates here as well.

Basically there will be package updates from time to time, but without a fixed release cycle.

You can also contribute package updates by pull request.

For very old releases of YOCTO there will be only a limited subset of tools available.

See the badge at the top of the README for details.

• Notice
• Differences to releases starting with thud
• Purpose
• Getting started
• Installation
  • Prerequisites
  • Use of containers
  • Setup
• Support
  • Release cycle
    • Releases
  • Compatibility
• Licensing
• Zero impact
• Available tools
  • Overview of tools
• Further documentation
• Contributing
  • Get involved
  • Security Policy

Purpose of this layer is to provide a proper set of static analysis tools for your YOCTO build. All provided tools can be easily configured and integrated into any CI service (like e.g. Jenkins).

All results are stored to SCA_EXPORT_DIR (which defaults to ${DEPLOY_DIR_IMAGE}/sca). The results will be stored in the raw-format of the corresponding tool and in checkstyle-format.

For a quick start how to use this layer see getting started guide

To install clone the needed brach(es) to any path on your local system.

• You need the sumo standard poky-layer installed onto your local build environment.
• You need at least python 3.4 needs to be installed on your build host.
• You need glib-2.0-dev installed on your build host (used for e.g. configcheck, lynis, tiger, upc)

It is recommended to use privkweihmann/yocto-sca-minimal:krogoth docker container for building, which has all necessary requirements already installed.

In your bblayers.conf-file add the following line

BBLAYERS += "<full path to sca-layer>/meta-sca"

or with poky layer already setup run in shell

bitbake-layers add-layer "<full path to sca-layer>/meta-sca"

Actively maintained branches will receive feature and package updates according to the release cycle. Unmaintained branches will only receive package updates on demand.

Status of the branches is described at SECURITY.md.

It's advised to use the tagged source versions in productive environment.

You can expect a new tagged build every 4-6 weeks for every actively maintained branch. Planning is done by milestone features on GitHub.

See SECURITY.md for details

If there is a technical issue that might break backward compatibility it will be mentioned in release note of the corresponding milestone release.

This layer does only provide open source tools. The layer itself is licensed under BSD.

If individual files are licensed under different terms, terms and conditions can be found in the individual file header

This layer provides only -native tools, so actually none of the build binaries will be deployed to your target. Everything happens on the build machine.

There are some excludes to this rule (e.g. lynis) as they need to be cross-compiled to make use of them, nevertheless none of these tools will be installed automatically to your build.

The layer can check on a recipe-level or on an image-level.

• On image-level the whole root-filesystem could be taken into account, which in most cases can't be granted on a recipe-level.
• On the other hand some static code analysis does not make any sense on an image-level - so this layer does have different tools for both level available.

each tool does have it's own benefits and flaws so don't be mad if you have 10k+ findings on the initial run.

• Global Configuration
  • Blacklisting sources
  • Configuration wizard
  • Custom severity
  • Enable SCA locally/globally
  • Fatal findings
  • Filter findings
  • Filter out files to check
  • Output formats
  • Suppress findings
  • Tools
    • bandit
    • bashate
    • bitbake
    • checkbashism
    • configcheck
    • cppcheck
    • cpplint
    • darglint
    • dennis
    • detectsecrets
    • flake8
    • flawfinder
    • flint++
    • gcc
    • gixy
    • jsonlint
    • kconfighard
    • looong
    • lynis
    • msgcheck
    • multimetric
    • mypy
    • nixauditor
    • oelint
    • perl
    • perlcritic
    • pscan
    • pyfindinjection
    • pylint
    • pysymcheck
    • pytype
    • rats
    • ropgadget
    • safety
    • setuptoolslint
    • sparse
    • splint
    • systemdlint
    • tiger
    • tlv
    • tscancode
    • upc
    • vulture
    • xmllint
    • yamllint
    • yara
    • zrd
  • Extra modes
    • BestOf
    • Image Summary
• Configuration Examples
  • C/C++ code while developing
  • Image monitoring
  • Image security/hardening monitor
  • Python code while developing
  • Shell code while developing
• Results
• Build system integration
  • Control via command-line
  • Jenkins integration
    • Basic jenkins integration
    • Parameterized jenkins build
• Application notes
  • Recipe buildtime dependencies
  • How are the statistics of a tool calculated?
• Case studies
  • Regression on severe code issues
  • Idenfying hardening and security potential

Feel free to create pull-requests or create an issue if you think there is something wrong or missing.

To get involved following things can be done

• create an issue
• fix an issue and create a pull request
• see the pinned issues in the bugtracker

For the project's security policy please see here