The importance of security in the dynamic digital world of today cannot be emphasized enough. As our reliance on technology expands, protecting the security and integrity of our digital assets becomes essential in both our personal and professional life. If you’re interested in learning more about the importance of cybersecurity and its wide-ranging effects, you should definitely check out our article on why a cybersecurity program is crucial.
Unveiling SAST and DAST
Moving to specific aspects of software application security, we encounter two fundamental methodologies: Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST). They are critical in identifying vulnerabilities in software applications, with SAST analyzing source code at rest and DAST assessing applications in a running state. Together, they offer a robust framework for safeguarding software.
SAST is a white-box testing method that analyzes source code or compiled versions of code to identify security flaws. It does this without running the program, offering developers the advantage of finding and fixing vulnerabilities early in the development.
On the other hand, DAST is a black-box testing method that examines an application as it’s running. It simulates attacks on a web application to find vulnerabilities that could be exploited by an external attacker. DAST is critical for finding issues that only appear when an application is running, such as runtime errors and server configuration mistakes.
Both SAST and DAST are important in a comprehensive security strategy. By incorporating these methods, organizations can cover a broader range of potential security weaknesses, from code-based flaws to runtime vulnerabilities.
Quick Recap: Previous Sonar Pipeline Insights
In our ongoing exploration of software security and quality, we have previously delved into the intricacies of a centralized Sonar pipeline setup. This setup plays a crucial role in streamlining code analysis and upholding stringent quality standards. For an in-depth understanding of this, you can revisit our detailed discussion here: Prioritizing Code Quality: Centralized Sonar Pipeline Setup for openIMIS.
Within this context, we also presented a real-life application of Static Application Security Testing in one of our internal projects at SolDevelo. This example not only demonstrates the practical effectiveness of SAST in identifying potential vulnerabilities early in the software development cycle but also highlights how seamlessly it integrates with the centralized Sonar pipeline to fortify the security and robustness of our software solutions.
Choosing the Tools
SonarCloud for SAST Analysis
For Static Application Security Testing (SAST), we’ve chosen to integrate SonarCloud into our development pipeline. SonarCloud stands out as a cloud-based service that provides comprehensive code analysis for a wide range of programming languages. It excels in identifying bugs, vulnerabilities, and code smells, ensuring that the quality and security of the code are maintained throughout the development life cycle.
One of the key advantages of SonarCloud is its ease of integration with continuous integration/continuous deployment (CI/CD) systems, enabling automated code review with each code commit. This integration helps us maintain a high standard of code quality and security, right from the earliest stages of development.
The accompanying image showcases a SonarCloud analysis report for our openIMIS project. As depicted, the dashboard reflects a ‘Quality Gate Passed’ status, signifying that our codebase meets the stringent criteria set for reliability, security, and maintainability.
OWASP ZAP for DAST Analysis
On the flip side, for Dynamic Application Security Testing (DAST), our choice is OWASP ZAP (Zed Attack Proxy). This open-source tool is widely recognized for its effectiveness in finding security vulnerabilities in web applications during the runtime. OWASP ZAP simulates attacks on a web application to identify issues like runtime errors, server configuration mistakes, and other vulnerabilities that only become apparent when an application is running.
This tool not only complements our SAST efforts with SonarCloud but also provides an essential layer of security by testing the application from an external attacker’s perspective. Its user-friendly interface and powerful features make it a go-to choice for ensuring the runtime security of our applications.
The image of the OWASP ZAP scanning report illustrates the tool’s thorough examination of our web application, flagging various security issues categorized by risk level. The report indicates several medium and low-risk alerts, but notably, no high-risk vulnerabilities were detected. This kind of insightful feedback is critical as it allows us to address potential security flaws proactively.
Setting Up the Rules
Leveraging Default Rules for Optimal Balance
Our approach to implementing SAST with SonarCloud and DAST with OWASP ZAP is rooted in leveraging the default rulesets.
SonarCloud security rules are maintained by SonarSource, the organization behind both SonarCloud and SonarQube. Their team of security researchers and developers is tasked with curating and regularly updating these rules to align with the latest security vulnerabilities and coding best practices. This ensures that the rules stay current with the evolving threat landscape and adhere to modern security standards. For more detailed information on SonarCloud’s security rules and how they are maintained, you can read further at SonarCloud Security Related Rules.
OWASP ZAP, on the other hand, is a project from the Open Web Application Security Project (OWASP), a global open-source and not-for-profit organization focused on enhancing software security. The security rules for OWASP ZAP are developed and maintained by a diverse community of international volunteers. This community includes security experts, software developers, and users, all contributing their unique skills and knowledge. They collaborate to create rules aimed at detecting a broad spectrum of security vulnerabilities commonly found in web applications. For more information about OWASP ZAP and its community-driven approach to improving software security, you can explore their resources at the OWASP website.
This reliance on expert-selected rules strikes a balance between relevance, ensuring we are safeguarded against current and relevant threats, and efficiency, allowing our teams to maintain focus on development without the overhead of managing custom rule sets. By trusting these rule sets, we align ourselves with the best practices of the industry while also benefiting from the collective intelligence of the cybersecurity community.
Implementing SAST/DAST: Real-life Challenges
openIMIS: Implementing SAST from Scratch
The journey with the openIMIS project began with a significant challenge: the absence of any Static Application Security Testing (SAST) tool within the development pipeline. This gap not only posed a risk in terms of security vulnerabilities but also limited our ability to systematically assess and improve code quality. Recognizing this, we embarked on the task of developing a comprehensive SAST solution from the ground up.
The development process involved the selection and integration of SonarCloud as our SAST tool of choice. However, the challenge extended beyond simply choosing a tool. We needed to incorporate this into our existing workflow. This is where GitHub Actions played a crucial role.
The integration of SonarCloud, complemented by GitHub Actions, strengthens our approach to software development in openIMIS. Developers now receive immediate, actionable feedback on their code submissions. This quick insight has empowered them to address potential security and quality issues proactively, significantly reducing the likelihood of vulnerabilities making it to the production.
For a detailed look at how we tackled these challenges and optimized our security and development process in openIMIS, feel free to explore our article: Prioritizing Code Quality: Centralized Sonar Pipeline Setup for openIMIS.
openIMIS: How do we utilize DAST Analysis
The addition of Dynamic Application Security Testing (DAST) with OWASP ZAP further enhanced our security posture, providing a dual layer of protection alongside SAST. The combination of these tools offers a comprehensive view of both the static code and its behavior in a live environment.
To conduct effective DAST, we have established a dedicated repository for managing our security testing. This setup allows us to automate the process of setting up the environment and running the application in a manner closely resembling the production scenario across different modules.
The workflow is configured to automatically trigger DAST scans on a daily basis using OWASP ZAP. This consistent and automated approach ensures that we continuously monitor our application for new or evolving security threats.
The image captures a sequence of automated DAST scans, clearly indicating the consistency of our daily analysis regimen. As you can see, each entry is timestamped, providing evidence of the scheduled execution of DAST scans.
Alongside the automated scans, our GitHub Actions workflow also facilitates manual triggering of DAST scans. This option is invaluable for immediate security evaluations in various scenarios, such as after significant updates or before deployments. The ability to initiate scans manually provides an extra layer of security assurance, allowing us to respond swiftly to any concerns that arise.
Our continuous security monitoring through DAST has yielded valuable insights into the application’s vulnerability landscape. The most recent reports from OWASP ZAP present a structured view of the potential risks, segmented by their severity levels. Below is a summarized table from the report, which serves as a reference for the detected security alerts:
A deeper look at the DAST analysis suggests that our application has an interesting security profile. Notably, no high-risk vulnerabilities were discovered. The analysis does highlight three medium-risk warnings that, although not essential, require our attention in order to reduce any possible effect. Similarly, the three low-risk and three informational warnings provide chances for our security policies to be refined and improved. The lack of false positives highlights the accuracy of our DAST approach, allowing our development team to focus on the actual areas for improvement without being distracted by irrelevant warnings.
OpenLMIS: From SonarQube to SonarCloud
In the OpenLMIS project, we faced a unique set of challenges. The project was initially set up with SonarQube, paired with Jenkins for CI/CD processes. However, over time, it became evident that the ruleset in SonarQube was becoming outdated, and the Jenkins pipeline was not aligning with our evolving needs for agility and scalability. This posed a significant challenge, as the outdated tools could potentially lead to overlooked vulnerabilities and inefficiencies in the development process.
Recognizing the need for an update, we embarked on a comprehensive migration strategy. The transition involved two major shifts: moving our CI/CD processes from Jenkins to GitHub Actions and upgrading our SAST tool from SonarQube to SonarCloud. We invite you to read our Streamlining code quality and security in OpenLMIS blog post if you’re interested in the specifics of this migration and want to learn more about it. The article explores the subtle aspects of the changeover, the decision-making process, and the results of such an important shift.
Conclusion
Lessons and Best Practices
1. Keeping Tools Up-to-Date
The foremost lesson from our experience is the critical importance of keeping our security tools as current as possible. The rapid evolution of security threats means that tools which are not regularly updated can quickly become obsolete. This was particularly evident in our transition from SonarQube to SonarCloud in the OpenLMIS project. The shift to a cloud-based tool ensured continuous access to the latest updates and security checks, thereby significantly bolstering our defense against emerging threats.
2. Leveraging Default Profiles and Quality Gates
Another key takeaway is the effectiveness of using default profiles and quality gates in tools like SonarCloud and OWASP ZAP. These default settings are not only crafted by experts but are also continuously refined to reflect the latest security trends and best practices. By adopting these standards, we ensure that our projects are not only compliant with current industry benchmarks but also benefit from the collective expertise of the cybersecurity community.
3. Integrating Security into the Development Life Cycle
A crucial lesson is the importance of integrating security measures like SAST and DAST early and throughout theSoftware Development Life Cycle. This integration ensures that security is not an afterthought but a fundamental part of the development process. It allows for the early detection and resolution of vulnerabilities, reducing the potential for costly fixes later.
Looking Ahead: Expanding Our Security Horizon
Moving forward, our plan is to further implement and enhance SAST and DAST across our projects. Our commitment is to provide a high level of security and code quality. This is not just about staying ahead of potential threats but also about ensuring that our products meet the highest standards of reliability.
The journey with SAST and DAST is an ongoing one, and we are excited about the possibilities that lie ahead. We believe that by continually investing in these tools and practices, we can create software solutions that are not only secure and robust but also set benchmarks in the industry for quality and reliability.
