For this posting, I would like to introduce my joint guest author Naveen Gupta, who is a Principal Security Engineer in the SaaS Cloud Security (SCS) organization.

 

Oracle has a long-standing, secure development product lifecycle that is a core component of the Oracle Software Security Assurance (OSSA) program. OSSA is Oracle’s methodology for building security into the design, build, testing, and maintenance of its products, whether they are used on-premises by customers, or delivered through Oracle Cloud. One of the requirements of the OSSA program is to evaluate Oracle functionality throughout the product lifecycle using static analysis tools.

As mentioned in this Oracle blog, the Oracle SaaS Cloud Security (SCS) organization completes security testing during the DevSecOps cycle for SaaS applications such as Oracle Fusion Cloud. Static application security testing (SAST) is a white-box method of testing. SAST examines the source code to find software flaws and weaknesses that can lead to security risks. These risks are defined by various governing bodies and standards like OWASP, CWE, NIST, SANS, and PCI.

DevSecOps aims to embed security into every part of the development, delivery, and operations processes. As most security vulnerabilities get introduced at the time of the coding, it is essential to identify and fix them at the earliest possible stage of the development cycle. The SCS team completes static analysis during the coding stage. We use SAST tools to analyze the source code of the application and bytecode without executing the application.

Benefits of Using SAST Tools in SaaS

When it comes to SaaS, secure coding is non-negotiable. Cloud service providers simply cannot afford to implement insecure applications and software systems. In a typical SaaS environment, the software development lifecycle (SDLC) works with the traditional CI/CD (Continuous Integration/ Continuous Deployment) DevOps model. There are multiple advantages that SAST brings to the SDLC for Oracle SaaS applications. Some of these are:

(a) SAST tooling examines code in detail in the repository, thereby reducing the time and personnel required to identify potential security defects. Automated SAST tools are faster and can examine code more frequently, which is the very essence of a CI process.

(b) Conventional threat modelling cannot anticipate every possible technique that attackers can use  to exploit the vulnerabilities that can exist in software. These vulnerabilities exist because even smart developers can make coding errors that cause vulnerabilities in an application. The use of SAST tools during software development therefore acts as a reliable defense against common application threats and coding errors.

(c) SAST tools are integrated into the SDLC for Oracle SaaS. SAST helps to reduce the security risk in the application by enforcing checks at different phases. For example:

(d) During the development phase, the applications developers incorporate SAST into their development tooling (with integrated development environment (IDE) plugins) and workflow.

(e) At the build phase of the DevSecOps model, SAST tools are integrated into the software engineering system during CI/CD execution.

(f) Before deployment, security teams use SAST tools to scan applications for security vulnerabilities.

(g) In addition, some SAST tools can integrate with source repositories and automatically report vulnerabilities to defect tracking systems.

(1) SAST tools are executed early in the SDLC, minimizing the risk of critical or high vulnerabilities getting into a deployed SaaS application.

(2) SAST results are considered as evidence artifacts for SaaS applications that must comply with industry security audits like the Federal Risk and Authorization Management Program (FedRAMP) or Payment Card Industry Data Security Standard (PCI DSS).

Types of Vulnerabilities Found with SAST

Security vulnerabilities that we identify during the phases of the DevSecOps model often fall into the following types:

- Input validation and representation
- Application Programming Interface (API) abuse
-  Authentication
- Authorization
- Security features
- Errors
- Code quality
- Encapsulation
- Auditing and logging

 

Figure 1: SAST occurs during the (Plan, Code, Build, Test) phases of the DevSecOps cycle

SAST tools work directly on the source code, using an inside-out approach to perform security testing. SCS analyzes the results from the scan reports for multiple vulnerabilities to identify security issues. We use in-memory graphs to identify any untrusted data entry points (sources) and the point where the vulnerability (sink) manifests during code execution.

What do SAST tools find?

During SAST, we analyze for these vulnerabilities:

(a) Buffer overflow vulnerabilities that involve writing or reading more data than a buffer can hold

(b) Mistakes, weaknesses, and policy violations in application deployment configuration files like web xml

(c) Security violations by checking on dynamic HTML content that includes Java Server Pages (jspx), Javascript (js), Java Server Faces (jsff) files, etc.

(d) Time-of-check to time-of-use (TOCTOU) issues that can result in potentially dangerous sequences of operations

(e) Vulnerabilities that involve tainted data (user-controlled input) put to potentially dangerous use; for example, issues like injection or cross-site scripting (XSS)

(f) De-references of pointer variables that are assigned the null value

(g) Dangerous flaws in the structure or definition of the program; for example, violations in secure programming practices such as deprecated code functions, and objects not defined as static or final when required

(h) Dangerous uses of functions and APIs at the intra-procedural level; for example, unsafe calls that trigger buffer overflows, format strings, and execution path issues

How SCS uses SAST Tools

The Security Testing Services (STS) team provides code-scan services using SAST tools for various Oracle SaaS applications. The team helps with analysis of the identified security issues. The team also maintains a repository of scan artifacts in a centralized, role-based access control (RBAC) server for audit and review purposes. During result analysis, a security issue is classified as follows:

In addition to running SAST tools, the SCS team works on researching and implementing industry-best practices to reduce false positive issues. The team also trains developers on how to use SAST tools and analyze the results. Development teams that are skilled in using SAST tools can find and fix actual problems faster than teams who must spend additional time in understanding the tool and scraping through false positive results.

Millions of lines of code: Automation to the rescue

The SCS team builds and deploys SAST automation as part of the Automated SaaS Cloud Security Services (ASCSS) infrastructure at Oracle. We develop this automation to be integrated with existing SaaS applications and upcoming SaaS micro-services.  

In Oracle SaaS, we integrate on-demand scan processes with our central build orchestration system. The integrated automation suite triggers scanning jobs on-demand for a given SaaS application such as Oracle Fusion. In addition, for next-generation SaaS micro-services, we added automation into the code scan of a service as part of the Continuous Integration process (see Figure 2).

 

Figure 2 Example integrated Code Scan report in CI pipeline

How do we deal with false positives?

Historically, most SAST tools, based on their purpose, generate a lot of false positives. Independent SAST analysis of source code performed by third parties with only indirect knowledge of the specific applications has limited value. Fully leveraging SAST tools require in-depth understanding of how the application is architected and functionally operated in a production environment. Some of the recommended practices to overcome the challenge of false positives is to perform the following tasks:

(1) Create custom rules with validations to reduce false positives and apply during the scan time

(2) Apply a filter file containing a list of non-issue categories during the scan time

(3) Create a set of visibility filters to hide false positives from the audit view

While custom rules and scan-time filters remove the issue completely from the scan result file, visibility filters are used to hide the issue from the audit view. SCS follows a set of industry practices for SAST tools to hide the false positive issues while performing the audit for SaaS properties.
 

Conclusion

Application security testing is fundamental to Oracle and all SaaS applications as one of our core DevSecOps principles. It is an engineering area that invokes significant passion and results from security minded engineers. One of the recommended engineering practices is to always have automated SAST testing as a component of the coding phase of a DevSecOps model. The use of SAST by the SCS team is another example of Automated SaaS Cloud Security Services (ASCSS) infrastructure at Oracle. We will continue to provide additional examples of the DevSecOps processes and tools that we use in Oracle SaaS Cloud Security in future blog posts. We welcome your feedback and questions and we will continue to share content and posts based on your requests.