Yet another security tool to help us in Wego lockdown our infrastructure and
applications is more than welcome. One of the tool we use to help us point out
possible holes in our system and plug them before disaster happen is SLScan. SLScan is an open-source security audit tool sponsored by Shiftleft Security. SLScan help us

• credscan - scan for credentials leak where we might accidentally embed secrets in our source
• sastscan - static analysis/application security testing that may detect buffer overflow, sql injections, cross site scripting and others
• depscan - dependency audit through Common Vulnerability and Exposures (CVE) - remember left-pad incident in nodejs
• license violation
• container scanning through CVEs

SLScan is run as the last step in our Jenkins CI/CD setup. At this time, it is merely recommendatory - builds will not fail if SLScan find vulnerabilities - as we still have bug fixes and features we need to deploy. We're plugging holes slowly but surely.

SLScan can be installed and run as a agent in Jenkins or as a Docker instance provided by the official Shiftleft docker hub. We went with running the scan inside the docker instance and just mount a volume with our application codes to be scanned. This gives us freedom tracking and upgrading SLScan version to install and rebuild and restart Jenkins.

Once SLScan found a vulnerability, we send a slack message to a dedicated channel tagging the team what owns the project. The slack message contain a link to the Jenkins build where the issue was detected and links to reports to view the details of the vulnerabilities found.

There might be cases in which we know the vulnerabilities and understand the risk but is not able to address at this point in time, a threshold can be given to suppress the alerts. Once this threshold is broken, it means something fishy was added that could increase our risk of being compromised. It can be done by adding a .sastscanrc file in the root of your project that looks like

{
  "build_break_rules": {
    "Secrets Audit": {"max_critical": 20, "max_high": 25, "max_medium": 10}
  }
}

Credential scan tells us that we might have a piece of code that can leak secrets. It's mostly as a result of putting writing secrets such as session key, access key or jwt signing key in a file and checked into the code repository. Secrets shouldn't be checked in and shouldn't be in a filesystem but depending on which framework and how old your codebase is, compliance is going to be tricky with all the workarounds you have to do.

Dependency audit scan looks into the external libraries used by your project to check if the versions used has a known vulnerabilities and will suggest an upgrade if needed. It does this by comparing the library and its version to the CVEs.

According to WhiteSource,

Static application security testing (SAST), one of the most mature application security testing methods in use, is white-box testing, where source code is analyzed from the inside out while components are at rest

SAST scans helps us comply with secure coding standards and best practices and common vulnerabilities like buffer overflow, SQL injection and cross site scripting.