Often security engineers find it difficult to scale secure code review processes either due to lack of funding, adoption to smaller sprint cycles or even security engineers failing to integrate security to agile philosophy. This post talks about various ways to address such challenges.
Challenges
Code Inventory
One of the primary challenges for the application security team is to know where all the source code lives. Organizations use one or more SCM solutions that are deployed in the internal network, Cloud or both. In addition, engineering teams may create organizations using their personal account that is not tied to the company which makes it harder for security teams to find. It becomes especially harder for large enterprises or enterprises with many subsidiaries and entities due to M&A.
Prioritization
Once the code repositories are mapped, the next challenge is to identify which ones pose a high security risk as not all source code has to go through the review process. It is not trivial to gain context and understand what the code does at scale to prioritize the repos for review.
Rapid Development
Scaling secure code review programs poses a significant challenge due to the accelerated pace at which development teams write and deploy code. This problem is further compounded due to an adoption of AI pair programmers, Agile philosophy and adoption of DevOps. As a result, manual code reviews often become stale very quickly, hampering the productivity and efficacy of security teams.
Integration of Third Party Libraries and Services
Modern software development extensively relies on the integration of both first-party and third-party libraries and vendor services. As a result, it is critical to review and secure the integrations to improve the overall security posture. However, the challenge lies in determining the actual use of 1st and 3rd party libraries in the source code as opposed to libraries listed as dependency in config files and ensuring timely patching to address vulnerabilities. Similarly, it is time consuming to assess the use of third party APIs. These are especially hard within large-scale enterprise environments where numerous applications and dependencies are interconnected.
False Positives and Remediation
When scanning code using an out-of-the-box static analysis tool, it is common for a significant number of findings to be generated. Consequently, security engineers may need to invest several days or even weeks in the triage process. This involves a thorough review of the finding description, data flow graphs, and any additional insights provided by the tool. The goal is to determine whether each finding is a true positive, duplicate or a false positive and enumerate all the findings to fix. But, without prioritization of the findings and creating security roadmaps, developers could be fixing the symptoms without addressing the root cause.
Opportunities
Discover and Prioritize Manual Reviews
Collaborate with IT and Engineering to create public repos using enterprise accounts and build a code inventory to track all the repositories. By prioritizing high-risk repositories, the security team can allocate their resources effectively and focus on securing the most critical areas of the codebase. You can use insights and metadata about the source code for prioritization. Here are few data points to consider:
- Security related functionality (eg: AuthN/AuthZ, encryption)
- Integration with 3rd party APIs (eg: Public Cloud Services, Payment services),
- Data types handled (PII, Sensitive data)
- Custom Frameworks
- Code churn
- Vulnerability rate
You can create custom rules and use signals from static analysis tools like Bearer to automatically extract some of these data points.
CI/CD Integration
To keep pace with the rapid development cycles, automated security testing becomes essential. Static Application Security Testing (SAST), Software Composition Analysis (SCA), Secrets detection, and other security tools can be integrated into CI/CD pipelines to identify vulnerabilities and security weaknesses automatically. Automation allows for continuous security validation, reducing the time and effort required for manual review.
Strategize the Rollout of Automation Tools
The first step is to identify a handful of repositories based on their criticality and potential impact. This allows for focused efforts on high-risk areas. Next, customize the static analysis tool by creating a ruleset for each language that encompasses the specific security requirements and aligns with the organization's risk profile. It also helps in minimizing the number of unwanted findings and false positives. This ruleset serves as the foundation for future scans. After setting up the ruleset, a comprehensive scan is performed across the selected repositories. The findings from the scan are then reviewed by security engineers (in collaboration with engineers), who also conduct manual code reviews to validate and provide additional insights. Based on this, custom rules may be written to address any identified gaps. For example: You can write a rule to identify usage of OpenAI within your organization. Once the rule set is refined, the static analysis rollout can be extended to all other repositories, ensuring consistent security assessment throughout the organization's codebase.
Developer Education
While automating the identification of security risks before reaching production is valuable, it is equally important to establish and promote secure coding standards that guide developers in writing secure code from the outset. By analyzing the findings generated by security tools and manual reviews, the security team can compile a list of the top 10 risks specific to each engineering team and organization as a whole. This information becomes instrumental in designing targeted security training and security programs aimed at addressing these identified risks and improving the overall security posture of the organization.
Secure Defaults and Paved Roads
Engineering and security organizations must collaborate to establish secure-by-default "paved roads" that minimize the likelihood of introducing vulnerabilities into products. This concept facilitates the scalability of security teams by proactively preventing certain classes of vulnerabilities through intentional design, and enabling engineering teams to discover and fix security issues in their workflows.
This post was written by Karthik Ganesh. Karthik is a security engineering manager at a big tech company. He is passionate about building and scaling application security programs. He likes mentoring and guiding individuals in their pursuit of a successful career in the application and product security field.
