Over the past few weeks, we’ve published a series of blogs related to CWEs: we’ve taken a look at the changes in the Top 25 Most Dangerous Software Weaknesses over the past year, as well as some of the vulnerabilities included on the list:
- CWE-22: Path traversal
- CWE-611: XML external entity references
- CWE-78: OS command injection
- CWE-79: Cross-site scripting
- CWE-89: SQL injection
- CWE-200: Sensitive data exposure
- CWE-918: Server-side request forgery (SSRF)
- CWE-77: Command injection
With that information in hand, what can someone in software engineering or application security do about possible security risks in their code?
Finding weaknesses and vulnerabilities
The first step toward determining how secure your application is is to find as many of the vulnerabilities that are present in your application as possible. There are various tools that you can use at different parts of the software development lifecycle (SDLC).
There is a time and place for each type of security tool. Linters are great for near-instantaneous feedback during the development process. SAST is a good option for integrating into your pull request pipeline and is often bundled with SCA for use with open-source packages and libraries. DAST tools are excellent for detecting existing vulnerabilities in production code that can be triggered.
In the end, the best option is to mix-and-match options so that your engineers are getting feedback at all points of the SDLC. Once you’ve gained this information, including whether you have any CWEs present, you can continue by learning the best methods for mitigating these issues.
Mitigating identified weaknesses and vulnerabilities
Once you have a list of the weaknesses and vulnerabilities, including CWEs, that are present in your application, you can begin mitigating them to lessen the risk of your application being compromised:
- Sanitization of all user-provided input
- Encryption of data
- Use of libraries or frameworks to implement features security
- Updating libraries and frameworks used to leverage security fixes
- Minimizing the attack surface
The specific technique that applies is dependant on the vulnerability present in your code. Different issues require different fixes, so in some cases, the first step might be to learn about the topic, why it is problematic, and what the best courses of action could be (and from there, narrow down the results that best fit your needs).
SCA and Prioritization
That said, there’s a possibility that the sheer number of vulnerabilities present may be overwhelming. In that case, you may want to leverage the power of an SCA tool. These tools, typically bundled with SAST options, allow you to determine the vulnerabilities introduced via open-source libraries.
More importantly, some will prioritize them based on whether they are attacker-reachable. For example, a vulnerability that cannot ever be reached is a lower priority than one that can be. Just as first responders triage, so too can your AppSec team triage the security threats to your application.
Visit ShiftLeft Learn to continue your application security education today!
Top comments (0)