Security Code Review

Tenendo code review approach leads to detecting many vulnerabilities in real-world software and achieving amazing results, in comparison to other approaches.

Poor code quality leads to vulnerabilities and errors in the code, which not only makes it vulnerable to attacks but also fragile and unstable.

Almost all code-level vulnerabilities are the result of unsafe coding techniques and inadequate testing. To prevent these errors, you must adhere to secure coding standards and guidelines.

Software vendors should thoroughly test all application features to verify stability and security levels prior to release. Customers should require products to be tested by a third party and to eliminate vulnerabilities before accepting the product.

Avoiding insecure coding practices in the initial stages of the Software Development Life Cycle (SDLC) can minimize the time and effort spent on finding and fixing them in later stages and the losses to humanity on this account.

Knowledge about the presence of security vulnerabilities in a programming language does not solve the issue completely unless the developer remains security conscious during software development phases.

There are two ways of detecting security vulnerabilities in a program:

Static Analysis

Static Analysis is carried out statically without executing the code. In this method the tool inspects input program code for possible security vulnerabilities and alerts the user.

Dynamic Analysis

Dynamic Analysis is carried during the execution of a program. Dynamic analyzer monitors system memory, functional behavior, response time, and overall performance of the program to find security vulnerabilities.

Tenendo security code review solution:

A standard Tenendo approach is to address insecure code issues is an analysis that tries to detect if a value coming from a source (e.g., methods retrieving some user input) flows into a sink (e.g., methods executing SQL queries) without being sanitized (e.g., properly escaped). This generic schema has been instantiated to several critical security vulnerabilities in the OWASP Top 10 list, such as:

  • SQL injection, where sources are methods returning user input, sinks are methods executing SQL queries, and sanitizers are methods escaping the input;
  • cross-site scripting (XSS), where sinks are methods executing the given data;
  • redirection attacks, where sinks are instead parameters of methods opening an Internet connection; and
  • leakages of sensitive data.

Tenendo approach leads to detecting many vulnerabilities in real-world software (e.g., web servers) and achieving amazing results, in comparison to other (usually pattern-based) approaches.

Preparation

Preparing for a security code audit requires careful planning and collaboration between all parties involved. This begins with Initiation and involves several activities:

  • Initiation: Upon initiation, Tenendo contacts the sponsor, typically within one business day, to acknowledge receipt, coordinate the planning session date and time, and issue invitations to the necessary stakeholders.
  • Planning Session: The planning session is conducted as scheduled. Led by the assigned Tenendo project manager, the scope of an audit is reviewed, technical requirements are discussed, scheduling and other planning considerations are covered. Time is reserved during the planning session for other questions or considerations stakeholders may have.
  • Project Plan Issued: Following the conclusion of the initial planning session, Tenendo develops a project plan containing the specifics discussed during the planning session. The project plan is issued, accompanied by a summary of open items, and updated throughout preparation as activities are completed.
  • Communication Channels Established: During this phase, Tenendo and project stakeholders establish communication channels that will be used during the project: project management and technical communication, emergency communication.

Code Inspection Workflow

Input

At a minimum, the code must be available when you conduct the code review. Additionally, the following can help:

  • Architecture or component diagrams
  • Data flow
  • Data schemas
  • Descriptions of specific application protocols, encryption mechanisms, authentication process, communication points such as user interfaces and APIs.

Output

The output of the code review activity is a set of identified vulnerabilities with their descriptions and impact ready to be prioritized for repair.

Security code review steps

Tenendo formalizes the security code review process by conducting code inspection in several steps with defined results of each. Although tactics, tools, and procedures vary depending on the scope and technology, process stages are very similar and include:

Step 1. Identify security code review objectives. Establish goals and constraints for the review.

Step 2. Perform a preliminary scan. Static analysis is used to find an initial set of security issues and to improve understanding of where security issues are most likely to be found by a closer look at the code.

Step 3. Review the code for security issues. Review the code thoroughly with the goal of finding security vulnerabilities that are common to many applications. Results of Step 2 are used to focus analysis.

Step 4. Review for security issues unique to the architecture. Complete a final analysis by looking for security issues that relate to the unique architecture of the application.

Security code review steps

Integration with existing SDLC processes

To ensure the security and quality of the entire Software Development Life Cycle (SDLC), we need to take many important measures and use the right tools for the job along the way. It is much easier to track and fix the security issues by incorporating security functionality into the software application at the building stage. Activities related to security code review and integrated into SDLC:

  • Integrate secure coding principles into SDLC components by providing a general description of how the secure coding principles are addressed in Architecture and Design documents.  If a secure coding principle is not applicable to the project, this should be explicitly documented along with a brief explanation.
  • Perform automated application security testing as part of the overall application testing process. 
  • Development and testing environments should redact all sensitive data or use de-identified data.

Related services:

Security Assessment of the Architecture

Security Assessment of the Architecture

We will assess your architecture concept from the Information Security point of view and develop a baseline for your Secure SDLC and architecture hardening.

Read More
Red Teaming

Red Teaming

Discovering potential compromise paths. Test threat response, detection, and investigation processes.

Read More
Developer/DevOps adversary simulation

Developer/DevOps adversary simulation

With valid developer credentials for the infrastructure, we obtain access to existing CI/CD, logging, monitoring, and remote access solutions to build a complete threat model, find access control misconfigurations, and help companies ensure no single…

Read More

Need more information?

Post navigation