Fortify Alternate Sources

Our organization is presently utilizing Fortify Static Code Analyzer (SAST) and Fortify Dynamic Application Security Testing (DAST) for ongoing cybersecurity and testing operations. In our pursuit of identifying possible alternative solutions, we are conducting market research to assess products and services that can fulfill the specific criteria outlined below.

The organizational objectives of this research are as follows:

1. Identify and catalog available products and solutions in the market.
2. Evaluate the features, functionality, and pricing of each alternative to determine its suitability for our needs.
3. Assess the level of integration and compatibility of each alternative with our DevSecOps platform, while ensuring compliance with DoD security requirements.
4. Estimate the level of government resources required to migrate to a new solution, while maintaining our current operational capabilities.

The following are several key characteristics that we are employing to align with our organizational objectives, as previously stated above. Please note that this list is not comprehensive, but it does offer an overview of some of the most critical requirements for our specific environment:

1. To meet DoD CIO DevSecOps Reference Design compliance and perform continuous cybersecurity and testing activities, the tool must provide the following features:
   1. Software must be containerized and deployable through helm charts.
   2. Language: should support a wide range of programming languages, including popular languages like Java, C++, Python, and JavaScript, as well as C#, TypeScript, CSS, HTML, Go, PHP, Helm, Java, JavaScript, Python, XML, Terraform, Ruby, Scala, Swift, Objective-C, C, C++, PL/SQL, T-SQL, and VB.NET. This broad language support ensures that the tool can be used across different development environments and can identify vulnerabilities in a variety of codebases.
   3. Integration: should be able to integrate with other development tools, such as IDEs, build systems, and CI/CD pipelines.
   4. Customization: should allow for customization of rules and policies to align with the organization's security standards.
   5. Reporting: should provide comprehensive and actionable reports, highlighting vulnerabilities and prioritizing remediation efforts, Ex: should be able to make RestFUL API calls and trigger code scans and pull down the scan results.
   6. Compliance: should support compliance with industry standards, such as OWASP Top 10, SANS Top 25, and PCI DSS.
   7. Training and support: should provide training and support resources to help developers understand and remediate vulnerabilities.
   8. Speed and efficiency: should be able to analyze code quickly and efficiently, minimizing the impact on development cycles.
   9. Needs to support SAML integration for Single Sign-On (SSO).
   10. Licensing based on the number of lines of code scanned and no restrictions on # of users or frequency of scanning.
   11. Licensing based on the number of lines of code scanned and no restrictions on # of users or frequency of scanning.
2. Static application security test and scan (SAST)
   1. Static code analysis
   2. Source code linting
   3. Source code test coverage
   4. CI/CD integration
   5. Customizable security scanning and reporting
   6. The tool must integrate with various package managers to provide security testing during the build process and applications, but as a minimum package managers must include the following: Maven, Gradle, NuGet, NPM, and RubyGems.
3. Dynamic Application Security Testing (DAST)
   1. Web application scanning: should be able to scan web applications and APIs to identify security vulnerabilities such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF).
   2. Comprehensive testing: should be able to test all layers of the application stack, including the network, application, and database layers.
   3. Automated testing: should be able to automate the testing process, reducing the manual effort required to identify security vulnerabilities.
   4. Integration with development tools: should be able to integrate with development tools such as IDEs, build systems, and CI/CD pipelines to provide a seamless integration of security testing into the development process.
   5. Reporting and remediation: should be able to provide detailed reports of security vulnerabilities and recommend remediation steps to address them.
   6. Support for a wide range of technologies: should support a wide range of technologies, including web application frameworks, programming languages, and protocols, to ensure comprehensive coverage of the application stack.
   7. Scalability: should be able to scale to handle large web applications and APIs, as well as multiple applications and services.

                  Our organization will consider both commercial and open-source solutions.