From DevOps to DevSecOps: Tools of Transformation

A couple of years ago, Uber - the ride-sharing app, revealed that it had exposed the personal data of millions of users. The data breach happened when an Uber developer left the AWS access key in the GitHub repository. (Scenarios such as these are common since in a rush to release code, developers unknowingly fail to protect secrets.) Hackers used this key to access files from Uber’s Amazon S3 Datastore.

As organizations embrace the remote working model, security concerns have increased exponentially. This is problematic for healthcare and financial sectors dealing with confidential data. Leaders from the security domain indicate that there would be dire consequences if organizations do not shed their apathy about data security. Vikram Kunchala, US lead for Deloitte cyber cloud practice, warns that the attack surface (for hackers) has become much wider (as organizations shift to cloud and remote working) and is not limited to the “four walls of the enterprise.” He insists that organizations must consider application security a top priority and look for ways to secure code -  as the most significant attack vector is the application layer. 

Hence a new paradigm with an ongoing focus on security - shifting left. 

Shifting left: Tools of Transformation. 

Our blog, DevSecOps: When DevOps’ Agile Meets Continuous Security, focused on the shifting left approach. The shift-left approach means integrating security early in the DevOps cycle instead of considering it as an afterthought. Though quick turnaround time and release of code are important, security is vital. It cannot be omitted.  Here, in this blog, we will discuss how to transform the DevOps pipeline into the DevSecOps pipeline and the benefits that enterprises can reap by making the transition.  

At the heart of every successful transformation of the Software Development Life Cycle (SDLC) are the tools. These tools run at different stages of the SDLC and add value at different stages. While SAST, Secret detection, and Dependency scanning run through the create and build stage, DAST is applicable in the build stage. 

To provide an example, we can use a pipeline with Jenkins as CI/CD tool. For security assessment, the possible open-source tools that we can consider include Clair, OpenVAS, etc.

Static Application Security Testing (SAST) 

SAST works on static code and does not require finished or running software (unlike DAST). SAST identifies vulnerability and possible threats by analyzing the source code. It enforces coding best practices and standards for security without executing the underlying code.

It is easy to integrate SAST tools into the developer's integrated development environment (IDE), such as Eclipse. Some of the rules configured on the developer’s IDE - SQL injection, cross-site scripting (XSS), remote code injection, open redirect, OWASP Top 10, can help identify vulnerabilities and other issues in the SDLC. In addition to IDE-based plugins, you can activate the SAST tool at the time of code commit. This will allow collaboration as users review, comment, and iterate on the code changes.

We consider SonarQube, NodeJsScan, GitGuardian as the best SAST tools for financial technology. Among the three, SonarQube has an undisputed advantage. It is considered the best-automated code review tool in the market today. It has thousands of automated Static Code Analysis rules that help save time and enable efficiency. SonarQube also supports multiple languages, including a combination of modern and legacy languages. SonarQube analyzes the repository branches and informs the tester directly in “Pull Requests.”

Other popular tools for SAST are - Talisman and Findbug. These mitigate security threats by ensuring that potential secrets/sensitive information does not leave the developer's workstation.

SAST tools must be trained or aligned (in the configuration) as per the use case. For optimized effectiveness, one must figure a few iterations beforehand to remove false positives, irrelevant checks, etc., and move forward with zero-high severity issues.

Secret Detection

GitGuardian has revealed that it detected more than two million “secrets” in public GitHub repositories last year. 85% of the secrets were in the developers’ repositories which fell outside corporate control. Jeremy Thomas, the GitGuardian CEO, worries about the implications of the findings. He says, “what’s surprising is that a worrying number of these secrets leaked on developers’ personal public repositories are corporate secrets, not personal secrets.” 

Undoubtedly, secrets or codes that developers leave in their remote repositories (sometimes) are a significant security concern. API keys, database credentials, security certificates, passwords, etc., are sensitive information, and unintended access can cause untold damage. 

Secret Detection tools are ideal for resolving this issue. Secret detection tools prevent unintentional security lapses as it scans source code, logs, and other files to detect secrets left behind by the developer. One of the best examples of a secret detection tool is GitGuardian. GitGuardian's code searches for proof of secrets in developers' repositories and stops “hackers from using GitHub as the “backdoor to business.” From keys to database connection strings, SSL certificates, usernames, and passwords, GitGuardian protects 300 different types of secrets. 

Organizations can also prevent leaks with vaults and pre-commit hooks.         

Vaults: Vaults are an alternative to using secrets directly in source code. Vaults make it impossible for developers to push secrets to the repository. Azure vaults, for example, can store keys and secrets whenever needed. Alternatively, secrets can be used in Kubernetes.                                                                                                                                     

Pre-Commit hooks: Secret detection tools can also be activated with pre-commit tools, such as the tools embedded in the developer’s IDE to identify sensitive information like keys, passwords, tokens, SSH keys. 

Dependency Scanning 

When a popular NPM module, npm left-pad (a code shortcut), was deleted by an irate developer, many software projects for Netflix, Spotify, and other titans were affected. The developer wanted to take revenge as he was not allowed to name one of his codes "Kik," as it was the name of a social network. The absence of a few lines of code could have created a major catastrophe if action was not taken on time. NPM decided to un-publish the code and give it to a new owner. Though it violated the principles of “intellectual property,” it was necessary to end the crisis.    

It is beyond doubt that if libraries/components are not up to date, vulnerabilities creep in. Failure to check dependencies can have a domino effect. If one card falls, others fall as well. Hence the need for clarity and focus because “components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.” 

Dependency Scanning identifies security vulnerabilities in dependencies. It is vital for instilling security in SDLC. For example, if your application is using an external (open source) library (known to be vulnerable), tools like Snyk and White Source Bolt can detect and fix all vulnerabilities.    

Dynamic Application Security Testing (DAST) 

DAST helps to find vulnerabilities in running applications. Assists in the identification of common security bugs such as SQL injection, cross-­site scripting, OWASP top 10., etc. It can detect runtime problems that static analysis ignores, such as authentication and server configuration issues and vulnerabilities - apparent when a known user logs in. 

OWASP ZAP is a full-featured, free, and open-source DAST tool that includes automated vulnerability scanning and tools to aid expert manual web app pen-testing. ZAP can exploit and recognize a large number of vulnerabilities.

Interactive Application Security Testing (IAST) - Works best in the QA environment.  

Known as "grey box" testing, Interactive Application Protection Monitoring (IAST) examines the entire application. It has an advantage over DAST and SAST. It can be scaled. Normally an agent inside the test runtime environment implements IAST (for example, instrumenting the Java Virtual Machine [JVM] or the.NET CLR) - watches for operations or attacks and detects flaws. 

Acunetix is a good example of an IAST tool.

Runtime Application Self Protection (RASP)

Runtime Application Self Protection (RASP) is server-side protection that activates on the launch of an application. Tracking real-time attacks, RASP shields the application from malicious requests or actions as it monitors application behavior.  RASP detects and mitigates attacks automatically,  providing runtime protection. Issues are instantly reported after mitigation for root cause analysis and fixes.

An example of the RAST tool is Sqreen; Sqreen defends against all OWASP top 10 security bugs, including SQL injection, XSS, and SSRF. Sqreen is effective with its ability to use request execution logic to block attacks with fewer false positives. It can adapt to your application's unique stack, requiring no redeployment or configuration inside your software, making setup easy and straightforward.

Infrastructure Scan  

These scans are performed on production and other similar environments. These scans look for all the possible vulnerabilities: software running, open ports, SSLs, etc., to keep abreast with the latest vulnerabilities discovered and reported worldwide. Periodic scans are essential. Scanning tools utilize vulnerability databases like Common Vulnerability and Exposure (CVE) and U.S. National Vulnerability Database (NVD) to ensure that they are up to date. Open VAS, Nessus, etc., are some excellent infrastructure scan tools. 

With containers gaining popularity, container-specific tools like Clair DB are gaining prominence. Clair is a powerful open-source tool that helps scan containers and docker images for potential security threats.  

Cultural aspect 

Organizations must change culturally and ensure that developers and security analysts are on the same page. Certain tools empower the developer and ensure that they play a critical role in instilling security. SAST in the DevSecOps pipeline, for example, empowers developers with security knowledge. It helps them decipher the bugs that they might have missed. 

Kunchala acknowledges that organizations that have defense built into their culture face less friction handling application security compared to others. So a cultural change is as important as technology. 

Conclusion: Security cannot be ignored; it cannot be an afterthought

No one tool is perfect. Nor can one tool solve all vulnerabilities. Neither can one apply one tool to the different stages of the SDLC. Tools must be chosen according to the stage of product development. For example, if a product is at the “functionality-ready” stage, it is advisable to focus on tools like IAST and RASP. The cost of fixing issues at this stage will be high though. 

Hence the need to weave security at all stages of the SDLC. Care must also be taken to ensure that the tools complement each other. That there is no noise in communication and the management and security/development are in tandem when it comes to critical decisions.

This brings us to another key aspect if organizations are keen on incorporating robust security practices - resources. Resource availability and the value addition they bring during the different stages of the SDLC counter the investment costs.  
The DevOps team at MagicFinserv works closely with the development and business teams to understand the risks and the priorities. We are committed to further the goal of continuous security while ensuring stability, agility, efficiency, and cost-saving.

To explore DevSecOps for your organization, please write to us at mail@magicfinserv.com.