Software Security

Overview of section contents:

Section

Description

Enforce security of sensitive data

Use vault-like solutions to store sensitive data, such as passwords, security tokens.

Enforce security of continuous integration

ways to prevent the leaking of sensitive information when using Git, such as passwords, tokens.

Enforce security of the continuous deployment

Measurements to perform even when the CD tools may have failed to automatically remove the credentials

Security scans

Security scan to avoid vulnerabilities, particularly Python and Docker images

Automatic tools

The automatic tools to improve software quality

This section contains some best practices to keep the NSDF software stack safe and secure.

Enforce Security of sensitive data

The best approaches to store and share passwords, security tokens, sensitive information is:

  • Use 2-Step verification_, also known as multi-factor authentication (MFA) for all users: even if some password WAS stolen, it’s almost impossible to log in without a second device

  • Create_ short-lived tokens for any automatic procedure. This means to:() create the token and limit as much as possible its scope () use the token for a limited timeframe (*) remove the token while the activity is finished

  • Always follow the Principle of Least Privilege i.e. do not create security tokens with _Full Access _permissions.

  • Configure a strong password policy for users, and rotate keys (link)

To store sensitive data we suggest using a vault-like solution such as Confidant or HashiCorp Vault, both free for open source projects.

Enforce Security of Continuous Integration

Stealing passwords and tokens in a Git public repository can be as easy as running a single line command (link from “Ethical Hacker”) which dumps the contents of a repository’s object database :

{ find .git/objects/pack/ -name "*.idx"|\
while read i; \
do git show-index < "$i"|awk '{print $2}';done;f\
ind .git/objects/ -type f| \
grep -v '/pack/'| \
awk -F'/' '{print $(NF-1)$NF}'; }|while read o;do git cat-file -p $o;done|\
grep -E 'pattern'

The best approaches for these kinds of security leaks are:

  • Before pushing to GitHub: use truffleHog or gitleaks (or alternatives) to search for secrets, to dig into commit history and branches, to find secrets accidentally committed.

  • Before pushing to GitHub: clean up Jupyter Notebooks output or other clean-text documents using nb-clean (or alternatives)

  • After pushing to GitHub: use online open-source scanning solutions such as Spectral

Enforce Security of Continuous Deployment

All CD tools automatically filter secure environment variables and tokens r_emoving them from the _build log and replacing them with some obfuscated text. But, once a VM is booted and tests are running, all these tools have less control over what information utilities or add-ons can print to the VM’s standard output.

As an example, just running an env command from TravisCI, secrets will be publicly exposed (see Travis CI Vulnerability Potentially Leaked Customer Secrets).

Example of token leak on TravisCI

Possible countermeasures are:

  • Drastic countermeasures:

    • do a manual deployment and/or move your CI/CD pipeline on-premise.

  • Soft countermeasures:

    • disable all settings which duplicate commands to standard output (e.g `set -v ),

    • disable any displaying environment(e.g. env or printenv)

    • avoid printing secrets within the code(e.g. echo $SECRET_KEY)

    • avoid any shell commands that may expose tokens or secure variables (e.g. git fetch or git push)

    • avoid mistakes in string escaping

    • avoid increasing command verbosity if not strictly necessary

    • redirect output to /dev/null

    • rotate secrets periodically

  • Off-the-shell countermeasures:

    • use standalone solutions to do the online CD scanning

Security Scans

NSDF must constantly check source code for the most exploited security weaknesses and vulnerabilities in software including the:

This process should be automatic, ideally running on every new commit (i.e. several times /day), thus limiting the manual intervention to periodic full checks

Top used industry standards to asset software quality and security.

Also, NSDF recommends finding Python security issues using Bandit (or alternatives):

Bandit is a tool designed to find common security issues in Python code. To do this Bandit processes each file builds an AST from it and runs appropriate plugins against the AST nodes. Once Bandit has finished scanning all the files it generates a report.

and performing safety checks onP ython dependencies using:

  • Safety: a command-line tool to check virtual environment, requirement files, or any input from stdin for dependencies with security issues),

  • Jake: a tool to check for your Python environments and applications that can report on known safety vulnerabilities),

  • consider alternatives.

Finally, NSDF recommends adding Security scans of Docker Images.

Several security leaks are related to the Docker technology:

  • Security problems with the container image and the software running inside

  • Security problems regarding the interaction between a container, the host operating system, and other containers on the same host

  • Security problems related to the host operating system

  • Container networking and storage

To avoid such leaks, the simplest solution is to scan images during development (i.e. _run docker scan, Clair, Anchore, Dagda, Docker Benc before the Git pushing).

Also, consider following best practices from Docker official documentation:

  • Each container should have only one responsibility.

  • Containers should be immutable, lightweight, and fast.

  • Don’t store data in your container.

  • Containers should be easy to destroy and rebuild.

  • Use a small base image (such as Linux Alpine). Smaller images are easier to distribute.

  • Avoid installing unnecessary packages. This keeps the image clean and safe.

  • Avoid cache hits when building.

  • Auto-scan your image before deploying to avoid pushing vulnerable containers to production.

  • Scan your images daily both during production

Automatic scan on Docker Hub after the deployment is restricted to commercial accounts.

Automatic tools

See the “Software Quality/Tools” paragraph.

Almost all the automatic software quality tools also provide automatic checks for security and vulnerabilities.