fortify – Cyber Security Kings

Choosing a Static Application Security Testing (SAST) tool requires careful consideration, as not all SAST tools are equal. In the following article, I'll take a look at a few points I normally use in my evaluation criteria. What Are The Best SAST Tools? Static Application Security Testing (SAST) tools are designed to provide source code analysis techniques to find security flaws and vulnerabilities in developer code and provide best practise tips for better coding. SAST tools can integrate into the IDE offering a 'shift-left' security approach and can be integrated in CI/CD pipelines. Popular SAST tools include: SonarQube Veracode Static Analysis Fortify Static Code Analyser Codacy AppScan Checkmarx CxSAST There are many more tools available for SAST with many available in open source formats or as community editions. Before looking at the different popular SAST tools on the market, let's first find out what SAST is. What is SAST? Static application security testing (SAST) is the process of analysing application source code, binaries (also known as compiled code or byte code) for security vulnerabilities. The approach taken is static, that is the code analysis is done in a non-running state where the code is at rest and not in use. SAST software provides automated options in analysing code for security issues and offering advice on remediating code issues. In the rest of this article, we'll take a look at the SAST tools mentioned in the list ealier and what criteria needs to be considered when it comes to choosing the right SAST tool. 1. SonarQube Is SonarQube a SAST tool? SonarQube is a SAST tool used by many organisations. SonarQube provides static code analysis by inspecting code and looking for bugs and security vulnerabilities. The product is available as open-source and is developed by SonarSource. The Community Edition provides static code analysis catering for around 15 languages including Java, JavaScript to Go and Python, has vulnerability and bug detection, can track code smells, review technical debt with remediations, offers code quality history along with metric, can be integrated with CI/CD and has the capability to extend functionality further with over 60 community plugins. The Developer Edition has all the features of the community editions and more, catering for more languages, 22 languages to be exact (ABAP, C, C++, CSS, Flex, HTML, Go, JavaScript, Java, Objective-C, Kotlin, PL/SQL, PHP, C#, Python, Ruby, Scala, Swift, T-SQL, VB.Net, TypeScript and XML) and also includes injection flaw detection, real-time notifications in the IDE as part of SonarLint smart notifications, pull request decoration where information from the Pull Request analysis and the Quality Gate are added to the interface of the tools used to manage the Application Lifecycle Management (ALM). There is also an open source project by OWASP where there is a version called OWASP SonarQube. 2. Veracode Static Analysis Is veracode SAST or DAST? Veracode provides both a SAST and a DAST tool. Their SAST tool provides fast static analysis with automated security feedback, across the development environment (IDE integration) and from the CI/CD pipeline. A full policy scan is conducted before any deployment can be done, with clear guidance on the issues requiring remediation along with advisories on how to fix these issues. 3. Fortify Static Code Analyser Fortify Static Code Analyzer (SCA) from Micro Focus® assesses source code to find code issues as well as security vulnerabilities, along with advisories on how to remediate these issues. 4. Codacy If you need a tool that provides fast code reviews, codacy will come in handy. It is an automatic system that establishes data patterns to aid software engineers or developers in code reviewing. Codacy is a helpful tool in identifying any security issues and providing your code quality in the process. The tool has an interface to give you more information about the code you are running. It shows the quality of your project and its progress over time. It also provides information on whether there are hotspots in the code. By incorporating GitHub, codacy can check for errors, and you can identify the style and complexity of the code. Deploying codacy in your work saves you time when reviewing codes and helps you monitor the quality of your project with time. Codacy automates code quality by conducting static code analysis automatically, allowing quicker notifications of code coverage, security problems along with code duplication and code complexity. 5. AppScan AppScan provided by HCL (formerly by IBM) is a SAST tool for web application testing during the development process, with the goal of finding security issues, bugs and anomalies before code can be committed to production environments. Is AppScan Free? AppScan is available in a standard version with a FREE 30 day trial, designed to allow would be purchasers to try out AppScan by being able to run a limited set of scans. AppScan can be set up to run vulnerability checking tests automatically to hunt down any code vulnerabilities. Once these vulnerabilities are found, AppScan creates detailed reports with information on how to best remedy the findings. Along with the standard version of AppScan, there is also an enterprise version for larger organizations. Both versions are subscription based and require fulfilment each year to carrying using them for code analysis and reporting. 6. Checkmarx CxSAST Another useful static code analyzer is the Checkmarx CxSAST. It helps in checking for errors in the source code and detecting issues with security and regulation compliance. The system works by giving a flow of the code, then checking whether there are any issues. For each language, the system has a list of security vulnerability issues. You can configure or inquire about other issues yourself through the CxSAST auditing tool; you get either static reports or displayed on the interface. Not only do you get accurate feedback on your code, but you can also set the system to display false positives. The application allows the user to obtain security reports at any time in the cycle of the project. The CxSAST has an open-source analysis software that supports most languages; hence, an organization can effectively secure its code analysis components. The software can be integrated into the building of automation tools, software development, and vulnerability management. Checkmarx SAST (CxSAST) is a static analysis tool providing the ability to find security vulnerabilities in source code in a number of different programming and scripting languages. Differences Between SonarQube and Fortify SonarQube is a static analysis tool that is open-sourced, used for debugging, and detecting security issues. With the support of over twenty programming languages, it gives an automated analysis of any code. It accurately gives comments, bugs, and defects when the code is duplicated. Fortify is a software used in testing applications, especially for security reasons. It automatically detects when there are any violations in the rules of any language, especially security-specific guidelines. The tool translates the format of the source code, scans it, then gives a detailed report. SonarQube and Fortify are both static analysis tools; however, they differ in their design and functionality. The table below highlights some of these differences. SonarQubeFortifyIt is an open-source application.It is not open-source.The user can add configuration code as rules.The user can not add rules.The code upload is automatic.The user manually uploads codes.It is free to use.The user requires a license to use.SonarQube vs Fortify Both SonarQube and Fortify are useful static analysis tools with high accuracy in debugging and detecting security breaches. It depends on a company’s preference and whether the programs used are compatible with the tool. Other Types of Static Analysis Tools The following is a selection of some tools that you can use in static analysis. The tools are compatible with programming languages such as Java, C#, Python, and C++. Embold This software uses high-level technology to analyze data faster and give clear visuals. It employs the use of different lenses for analysis to provide the user with better software quality. The platform's high quality makes it fast in reviewing the codes; hence, it is faster in debugging the errors. The software allows the user to run it on IDEA or the cloud. Kuiwan It is an SCA and SAST platform static analyzer that deploys the latest technology and has features that surpass static analysis, making it a vast platform to implement in a DevOps. Raxis This system functions faster and more accurately compared to other software. If you need an analysis tool for security reasons, this platform will efficiently serve your company. You can also retrieve and archive your findings after the codes are reviewed to show management. RIPS Among all other platforms of analysis, only the RIPS is language-specific. It is one of the most thorough and complex tools that quickly detect code errors, making it highly accurate (no noise caused by false positives). The system integrates PHP and Java languages well, and it supports SDLC integration and meets the industry standards. PVS Studio This tool integrates well with IntelliJ IDEA, visual studio, Linux, Windows, and macOS. It debugs errors and detects when the security codes in programs are weak. When done with the analysis, you can import the results to SonarQube. Before you choose a tool for analysis, ensure that it will run well with your language, you can afford it, and you know it’s the purpose (commercial or open-source). Finding the Best SAST Tool To find the best SAST tool for your situation, a thorough investigation is required using the following criteria: SAST Performance SAST Security SAST Placement SAST Rule Control SAST False positives SAST Compliance Standards SAST Coverage SAST Advisories SAST Integration SAST Dependencies SAST Silver Bullet? A SAST tool is part of the whole security profile of development and deployment of code, other security elements like DAST, container security scanning and RASP need to be considered too. I'm not going to recommend any SAST tool, as most do a good job and one brand of SAST tool might be right for one organisation but may not right for another. However, I will look at the considerations required for choosing a SAST tool, as detailed below. 1. SAST Performance It's important to ensure any SAST tool selected doesn't slow down the development process as code is checked in and takes ages to scan, more so if it's done before a peer review process or as part of a pull process. If the tool is also incorporated in the CI/CD pipeline any effect on the time taken to analyse the code, affects the pipelines capability to work effectively. There's little point in selecting a tool that takes several hours to analyse code. As the delays in getting code analysis back, impact the time to also remediate the code and then regression test it all again. Becoming a major bottleneck in developing applications goes against the principles of DevOps where optimised delivery is key. Multiple tests There may be a need to run multiple tests, at the same time especially if there are different product teams working on different deliverables. Any SAST tool chosen needs multi-tasking capability to be able to meet these needs otherwise, there's going to be a slow down in delivery, as different teams code will end up in a queue waiting for another development teams code to be analysed by the SAST security tool. Bottlenecks must be avoided to ensure a limited impact on delivery and conformance to the principles of DevOps. Code Standards The standard of code being developed affects the speed of the SAST tool, as good quality standards will lead to faster analysis time. Code standards are important as they allow the number of alerts generated to be controlled as without code standards you'll end up with more alerts leading to more time to fix the alerts, even if they are false positives. While a wide variety of coding standards in use from different developers will lead to the time taken to analyse any issues with the code analysis using the SAST tool. By standardising on development, the time taken for analysis is reduced and when a developer leaves, it doesn't take more time to determine what they were actually trying to do. Many organisations rely on third parties to provide some or all of their code and this code will also need to be standardised. As this code could affect the static analysis performance. Can the SAST tool work with compiled code as well as source code? Compiled code (also called binary code and byte code) may require static analysis and some SAST tools have the capability to work with this type of compiled code. Does the SAST performance suffer when working with compiled code? Any trade-off in performance from the SAST tool to be able to deal with compiled code needs to be assessed during the evaluation. As this might be marginal or could be a bit hit on performance, making the SAST tool performance inoperable with an organisations DevOps plans. 2. SAST Security Many SAST security tools these days work on the SaaS model, where the tool itself is managed by the vendor and has some touchpoint that integrates into the customer's environment. This set up means the SAST infrastructure management is minimized as the vendor will be responsible for the most part but this also means there are security implications requiring consideration. The security considerations become more important when the code being developed is of high integrity and high-security nature. The implications of this sensitive code being sent externally to a vendor and their SAST SaaS systems for analysis will definitely require some form of risk assessment. As not only is sensitive code leaving the organisation, the security of the vendor and their SaaS solution also comes into the equation. Personally identifiable data shouldn't end up in SAST as SAST will be done without productionised data, if it does end up in the code then the code development SDLC and security around it needs to be carefully scrutinised from a security perspective. If the risk is too high to swallow then the only other option is to look at whether the vendor provides a 'self-hosted' solution, where the SAST tool is hosted in an organisations own environment. Secrets Management I normally check how the SAST tool handles secrets, as it could have secrets to allowing it to access repositories, pipelines and so on. If the SAST tool is handling these secrets insecurely, such as sending them across publicly using the internet without any form of encryption or authentication then this spells trouble. I would also check the privilege required by the role assumed by the SAST tool when it accesses repo's and the like, to see if it will only have least privileged access to be able to do its job. 3. SAST Placement The goal of using a SAST security solution is to not only improve the security posture of the code being analysed but also do this seamlessly without disrupting the delivery. To do this effectively, careful consideration needs to be done about the placement of the SAST security solution. The earlier the indication there is something wrong with the security of the code being developed, the quicker and more importantly the cheaper it will be to fix it. This "shift-left security" approach is essential to avoid ending up finding out about code security issues in pre-production and productions environments, where it can be very expensive to remediate, as the time to take applications affected by the insecure code out of commission and then remediate the insecure code, costs a lot more money and more time to boot. IDE Scanning Any SAST tool I'm evaluating is checked to see if it has the capability to do Day 1 secure code analysis, as this will make sure code insecurities are picked up during the development in a just in time fashion. This shifting to the left of the code analysis will help reduce coding issues earlier before they hit the CI/CD pipeline. Day 1 scanning starts when the developer starts to write code before any commits of code are made with some form of SAST analysis is taking place. The best place to do this will be in the developers Integrated Development Environment (IDE) and will be possible with the SAST solution having some form of a plugin for the IDE being used to develop code. By picking up issues quickly the developer can rapidly remediate the issues, well before they are committed into the merge with the master code branches. This will also mean any peer reviews won't waste time on issues that could easily have been fixed at the Day 1 scanning stage. I always look at whether the SAST security tool under evaluation has some for of IDE integration plugin for it to be able to do Day 1 scanning. A word of warning, the integration will mean the code is being sent to the vendor's SaaS SAST systems for analysis, so some form of risk determination needs to be done to make sure this is acceptable. Repository Scanning Another place where the code security analysis can take place is at the repository level (repo), so if GitHub is being used as a repo, this needs to be assessed for its ability to integrate with SAST services using an appropriate plug-in. Again, as before with the IDE integration with the SAST tool, the integration will mean the code is being sent to the vendor's SaaS SAST systems for analysis, so some form of risk determination needs to be done to make sure this is acceptable. Remember you will need to give the SAST tool authority to share repo access, so a private repo and the code it contains needs to be assessed for the risk of allowing the SAST tool to access this repo. CI/CD Pipeline Scanning Even with the IDE scanning and the Repo scanning in place, scanning in the Continuous Integration (CI part CI/CD) is essential. It may seem like overkill but the initial two stages of scanning are only there to speed up the development of the code by making sure the development of code is secure and doesn't come back to bite if discovered later on when the cost of fixing the insecure code will become much more expensive. The CI scanning is there for two reasons: Check the code sent to the pipeline is still secure, as it could be stale from the last time it was checked; Make sure the insider threat is minimized Code could have been reviewed but not merged into the master branch because of some delay or some additional functionality was added to the code and only the delta peer-reviewed, without considering the new functionalities impact to the whole code. This stale code could then easily creep through to the CI part of the pipeline and remain undetected if there's no further code analysis taking place. So even if there's a four-eye peer review process, the code is only as secure as the last time it's reviewed and how it's reviewed, whether it's reviewed from scratch as a whole or only additional deltas are reviewed. SAST testing needs to be done before any other form of testing is done in the pipeline, so any unit testing needs to be done after the SAST testing has been successfully navigated. This will reduce the time to fix issues before the unit and integration testing starts. Insider Threat With code security analysis only taking place at the IDE and the Repo level, this could leave the door open for malicious code developed by the developers to get into the CI/CD pipeline and make it's way further into productionised systems. Even with peer reviews, the threat of collusion between malicious parties is never fully avoided and people can change from being happy employees to being disgruntled employees to having external issues such as gambling debts, divorce and so on which clouds their judgement. So having code analysis at the CI level is a must, more importantly, this needs to be controlled with appropriate access rights and privileges to make sure it's not abused. When I run threat modelling workshops the insider threat is always overlooked or deemed low. We trust each other. Only takes one thing from gambling debts to a disgruntled employee. Additional Functionality Additional functionality to test the code functionally as well as securely using sandboxing is always a nice to have feature. Integration testing at this stage may not be possible as only stubs may exist but being able to test code and see any security issues is a big plus in my book. 4. SAST Rule Control The way in which the SAST tool does the analysis can be controlled on some SAST tools using rules. These rules have the potential to be abused and rigged if they are not properly controlled. There needs to be some form of fine-grained control over who can access the ability to create, change and delete rules using stringent Role-Based Access Controls (RBAC). A quality SAST tool needs to have the ability to work on least privilege by being able to control authorisation based on roles. RBAC is a must along with integration with an identity provider (IdP). I've worked on some tools where when I was checking through the controls, it's been easy to determine the SAST tool has been set to suppress warnings and errors, simply down the tool not being set to enforce RBAC type controls, with some Open Source tools allowing normal users to change configurations. Without the enforcement of roles and controls, the SAST tool can be abused, leading to insecure code being passed along the chain, potentially into production. 5. SAST False positives A good SAST tools goals need to be saving time in analysing code, with a minimal impact to the delivery schedules. Having too many false positives generated by a SAST tool can introduce delays to the delivery. As a specialist or team of specialists may be needed to analyse false positives to determine whether they are really appropriate. Training and maintaining a team of specialists is an expensive business, which again goes against the DevOps principles as automation should provide an effective opportunity to optimise. How good is a SAST tool at reducing false positive? I would look at the number it false positives generated by the tool being evaluated to determine whether this is satisfactory. Ideally comparing the number of false positives generated for the same code across a number of tools could easily give an indication of which tool is better. Better in the sense of having enough understanding to be able to determine what really is an issue and what isn't. Many SAST tools link into artificial intelligence with models developed from SAST scanning across many organisations to develop an understanding to eliminate the number of false positives generated. This expertise in code scanning is what you're really paying for, as the time saved from being more accurate in determining bad code from good code, means faster code analysis, leading to an optimised application delivery. How can you be sure a false positive that's ignored by one tool is really sinister and not a false positive? Again you can compare code analysis on the same code across SAST tools to see the different analysis. Then by reviewing the results, a determination of whether something that came up as a false positive across some SAST tools and wasn't picked up by other SAST tools, was really a false positive. If it was a false positive after analysing the results and there's a pattern of the SAST tool bringing up too many false positives, the SAST tool needs to be marked down in the evaluation process. Across SAST tools you get varying false positives for different SAST tools, good, bad at analysis determine. 6. SAST Compliance Standards Many organisations are either regulated or have to work to varying degrees of compliance and a SAST tool should be able to provide templates to facilitate compliance assessment. So if the organisation is developing payment software and needs to be PCI DSS compliant, then it would be an excellent idea to have PCI DSS compliance checking available in the SAST tool. SAST Compliance At a minimum, I would look at whether the SAST Vendor is SOC2 compliant as this provides some basic assurance they have been assessed to a standard. Using a SaaS service needs careful consideration, as having code go to a vendor's SaaS for analysis by the vendor's system might not sit well with people higher up the food chain in an organisation, so the risks will need to be understood and some form of third party assurance will need to be done. 7. SAST Coverage At a minimum, the SAST tool needs to have some capability of assessing to at least OWASP top 10 as these type of vulnerabilities I would class as typical 'schoolboy error' types. Validation checking is a must to ensure no rogue data can enter any applications being developed, along with checking for SQL Injection type attacks. The SAST tool aim is to find issues in code which could lead to security vulnerabilities, e.g. SQL statements haven't been prepared to lead to SQL Injection vulnerabilities. 8. SAST Advisories A good SAST tool needs to be able to where possible provide best practice security guidelines when it uncovers code where security looks weak. This advice needs to be developed by the SAST tool over time from drawing on the experience from other organisations and machine learning. By doing this the SAST tool is instrumental in getting the developers to write quality secure code. SAST tools which are new to the market may not have enough intelligence to be able to make good advisory decisions. By giving good code suggestions, lets the developer get a 'heads up' on defects, allowing them to be able to remediate issues knowing they are getting quality advice from the SAST advisory. 9. SAST Integration The SAST tool needs to be able to integrate with other systems and services, with an assessment of this potential to be assessed during any evaluation. Integration into a CI/CD pipeline is a given and this could be through automation services such as Jenkins or may involve some form of integration into cloud code pipelines like AWS Codepipeline. IDEs and Repositories As I stated earlier, integration with IDE's and Repo's is a good idea, so the capability to do this needs to be assessed as well as how securely the integration is done. SIEM Integration into monitoring and alerting services such as a SIEM is important especially from an auditing capacity, as access to tools and jobs run will need to be recorded. Identity Provider (IdP) Integration with an Identity Provider (IdP) is also essential as this will not only help with ensuring roles can be adhered to, with authentication and authorisation controlled but helps in any joining, leaving or moving or personnel, so access can be revoked at a single point and affect all systems using the identity provider. 10. SAST Dependencies There have been many companies that have been breached because one of the dependencies they used was itself hacked and altered, allowing malicious functionality to be included in the overall development code that allowed hackers to siphon off valuable data. It's imperative any dependencies being used are determined and then checked to see if these dependencies have any security issues. Many organisations seem to forget about checking the coding security of the dependencies they use in their software. Ideally, a SAST tool could include this but it will need to work in conjunction with a Software Composition Analysis (SCA) tool. Checking for vulnerabilities especially in Open Source components is necessary to ensure these don't introduce any risk to the applications being developed. 11. SAST silver bullet? Static Application Security Testing (SAST) isn't a Silver Bullet for all Application Security (AppSec) issues but it does provide an excellent way to help minimise security risk when used in conjunction with: a Secure Software Delivery Life Cycle (SSDLC); App Sec requirements; Threat Modelling; Dynamic Application Security Testing (DAST); Serverless/Container Security scanning; Penetration (PEN) testing; Red Team, Blue Team testing and so on. SAST tooling won't necessarily tell you there are issues with the configuration of the authentication and authorisation being used, whether the cryptography is secure. I'm always discovering developers using earlier versions of cryptography libraries which have known holes in them. What about cases where databases with personally identifiable information are being used by the application, with the connection configuration the database using insecure connections. Would this be necessarily picked up by the SAST tool? Making sure any dependencies used are secure and can't be compromised won't necessarily be flagged up by the SAST tool. For example, using JavaScript libraries from external sources introduces a relative amount of risk and careful scrutiny and control is needed to make sure these files don't end up being hijacked and used as a vehicle to inject rode code. These types of issues are all beyond the remit of the SAST tool and having security procedures and effective security training in place will help increase the organisations overall security. What Is a Static Code Analysis Tool? Without automation, it would take a long time to read, understand, and debug codes. With various static code analysis tools that you can use, we introduce you to static code analysis and identify the types of analysis tools used in the process. So, what is a static code analysis tool? A static code analyzer is an automated software system used by software engineers to check for flawed codes. Using specific tools for analysis, an organization can detect defects in codes and debug them early, saving them the cost of fixing it later. These tools are useful in reviewing codes before the program can be implemented. There are various static code analysis tools available, and each is unique in structure and functionality. It may be a challenge to choose the one that works best for you. Let us go into the details of static code analysis tools and find some of the most effective ones you can deploy. What Is Static Code Analysis Static analysis is the use of computer software to debug codes before the program is implemented. The process makes it easier and faster for software engineers/ developers to check for any flaws in codes, and since the process is automated, they do not need to read each line of code. The analysis helps detect errors in programming, coding violations, syntax errors, security breaches, and buffer overflows, making it an essential tool in detecting cybersecurity issues. There are various types of static analysis, including data analysis, control analysis, failure analysis, and interface analysis, and each class can be deployed in any department of an organization. An automated analysis system is more comfortable to use, faster, and more effective than having people do it. Doing it manually is tedious and may be prone to inaccuracies since we need to scrutinize each code. When deciding on the static code analyzer to use, it is vital to check that it is the correct code with the required standard to run according to the company's objectives. Also, check how complex the code is, how well the tool can detect the code's errors, and whether it is compatible with your programming language. Final Word Deploying a static analyzer lets you run your code before execution. In this way, you can check for flaws in the code and correct them early; hence, it saves you time and money. Technology allows you to customize the process according to your company's needs. With analysis tools such as SonarQube, Fortify, Appscan, and CxSAST, you can automatically and effectively detect the bugs before executing the code. Such systems are a great asset in each department in the company. Not only does it make it easier for software engineers/web developers to run their codes, but it is also a necessary tool in handling security issues. Related Questions: What is DAST tool? Dynamic Application Security Testing (DAST) tools automate the security testing of the application by looking for security vulnerabilities in the running state of the application. The DAST tool discovers security weaknesses by using a library of attacks to see which ones the application doesn't protect against. What is SAST and DAST? Static application security testing (SAST) analyses an applications source code for security weaknesses whilst the Dynamic Application Security Testing (DAST) tool analyses the application when it is running for security weaknesses. Disclaimer: I am in no way affiliated with, or endorsed or work for any of the organisations mentioned in this article.