Published July 8, 2020
WRITTEN BY THE KIUWAN TEAM
Experienced developers, cyber-security experts, ALM consultants, DevOps gurus, and some other dangerous species.
Developing correct and secure software isn’t easy. A typical application includes a large amount of original and third-party code, and it all has to work together without opening up security holes. Any change to existing code, whether it’s a simple refactoring or the addition of a major feature, could create a new risk.
Checking the code manually and running tests on the finished product won’t provide enough protection. Automated tools are necessary if you want a high level of confidence that the product can’t easily be hacked. Security testing needs to be integrated into the software development cycle.
Two major types of code security testing tools are static application security testing (SAST) and software composition analysis (SCA). The question isn’t “Which one do I need?” They serve complementary roles, and both are necessary to catch the greatest possible number of issues. Kiuwan provides both types of testing, letting you test all aspects of your software product.
The role of SAST
Static application security testing, also known as source code analysis, aims to find problems in the code that you develop. It examines the source code rather than the running application, hence is “static.” As part of the development cycle, it should verify all code before allowing it into a build.
SAST looks for patterns in code that may indicate vulnerabilities. Examples include:
- Failure to validate inputs
- Unchecked data conversions
- Uninitialized variables
- Lack of bounds checking
- Race conditions
- Use of previously freed storage
The checks will also find “dead” code that can never be reached, and which may indicate a logical error. Flagged code isn’t necessarily buggy; there may be checking at a higher level that eliminates an apparent risk. Still, anything flagged as a possible risk needs review. Developers will see the exact lines of code that are suspect, letting them make a quick decision. If they conclude the code is safe after careful checking, they can mark it as such.
Source code analysis is different from unit and component testing. It doesn’t run the code to determine if it produces correct results, but instead analyzes the code statically for errors and omissions. The fix may be as simple as adding a validation call, or in some cases, significant redesign may be necessary.
The role of SCA
In contrast with SAST, software composition analysis aims at finding problems with third-party code. Nearly all software today uses open-source or licensed libraries to perform commonly needed functions. It saves programming effort, and well-known libraries have already had extensive testing. They can still have bugs, though, including publicly known vulnerabilities that intruders can find.
SCA identifies the libraries used in a project and checks them against lists of known vulnerabilities, such as the National Vulnerability Database (NVD). Unlike SAST, it doesn’t require access to source code. In addition to finding vulnerabilities, it can check compliance with licensing requirements and project policies.
A software project should get periodic SCA scans even if it hasn’t changed, since vulnerabilities may have been recently discovered in the code libraries. When a scan discovers the problem, the remedial action is usually to find an updated library. If support for a library has been abandoned, more extensive changes may be necessary. Of course, any fix requires retesting the software to make sure it hasn’t broken anything else.
Even if SCA turns up a zero-day vulnerability with no fix, developers aren’t helpless. Usually they can mitigate it by putting additional testing into their code or tightening the configuration. At worst, they can temporarily disable some functionality.
Sometimes a flagged item doesn’t require a change. The code which invokes the library may render the vulnerability moot, or the application may not use the functionality that has the problem. It’s still important to record the issue and the reason for concluding there is no risk.
SAST and SCA work best together
Leaving aside “codeless” applications that consist of third-party libraries plus some glue, most software development projects make heavy use of both original and third-party code. Keeping both sides secure requires using both types of analysis together.
Kiuwan Code Security and Kiuwan Insights work together, delivering SAST and SCA respectively to ensure the most solid software product. Kiuwan Code Security provides automated code scanning, applying industry standards including OWASP, CWE, and others. Kiuwan Insights identifies vulnerabilities and licensing issues in frameworks and libraries. It can automate policies and recheck periodically for newly discovered vulnerabilities.
Kiuwan Code Security and Kiuwan Insights can be licensed for a single use, such as a software security audit, or for ongoing use.
SCA and SAST tools don’t eliminate the need for developer-designed unit and component tests. They don’t know what the code is supposed to do; all they can do is find ways it can go wrong. However, tests that developers and QA engineers create reflect their ways of thinking and often leave blind spots that don’t get tested. Automated tests are more consistent and thorough.
The software development cycle, SAST, and SCA
Frequent iteration has become the norm in software development, whether it’s called Agile, Extreme Programming, or CI/CD. These approaches validate every change in code before adopting it into the codebase, rather than accumulating huge amounts of change and then getting it to work. They require an automated process that checks the code thoroughly. Developers can fix bugs while the code is fresh in their mind and before other code has compounded the errors.
Regular testing will encourage developers to use better coding practices. If the tests turn up a lot of false positives, it could be a sign that the code is poorly structured and excessively convoluted. Cleanly written code is more likely to pass all tests, and it’s easier to maintain.
SAST and SCA are essential parts of this process. SAST checks the code which developers write, making sure they haven’t introduced bugs that are hard to spot in normal practice but vulnerable to exploitation. SCA checks for any newly discovered problems in third-party libraries or issues with newly added ones.
A thorough testing process with every release cycle reduces the odds of introducing bugs that spoil the user experience or compromise security. Contact us to learn more about how Kiuwan Code Security and Kiuwan Insights can improve your software releases.
Would you like to know more about implementing SAST and SCA in your organization? Get in touch with our Kiuwan team! We love to talk about security.