SECURE CODE REVIEW

WHAT IS A SECURE CODE REVIEW?

Secure Code Review is a specialized task involving manual and/or automated review of an application’s source code to identify security-related weaknesses. The review evaluates application code to identify flaws, weaknesses, or errors as a way to help developers improve security.

The RedLegg Secure Code Review engagement will consist of a manual review of the critical pieces of code within the application and will include:

  • Architecture and design review, and recommendations for improvements
  • Data boundary analysis identifying vulnerabilities
  • Level of trust, if any, implicitly provided to untrusted data sources or communication channels
  • Effective use of security protocols
  • Application of ciphers to sensitive data, both storage and transmission
  • Horizontal sampling of cross-cutting concerns for code quality analysis
  • Vertical sampling of transaction flows for code quality analysis
Pen-Test-Pillar-Banner

Pretty much everything you'd need to know about testing for different environments. 

LEARN MORE

BENEFITS

Benefits of a Secure Code Review performed by RedLegg include:

INSIGHT:

Gain insight into many of the risks faced within your enterprise by identifying shortcomings in your existing security program.

EFFICACY:

Prioritize the biggest threats to the organization and strategically plan the necessary roadmap to safeguard your organization.

PROACTIVITY:

Reduce the impact and likelihood of a successful breach and data exfiltration through testing and securing of your organization.

COMPLIANCE:

Show customers and stakeholders your commitment to securing and protecting the most valuable assets against various threat actors.

September 10 | Downtown Chicago

Penetration Testing Workshop

Pen Testing Workshops with RedLegg is a regional event series for cybersecurity professionals looking to build and expand their security strategies to grow and better protect their businesses.

REGISTRATION IS CLOSED

SECURE CODE REVIEW METHODOLOGY

A RedLegg Secure Code Review consists of manually reviewing the source code of a software system. This type of testing audits the existing source code for the application to validate proper security controls, logic, functionality, organization, and effective use of language. Specifically, this effort consists of assessing security, language, design, and architecture.

Download The Sample Report

 

333
PHASE 1:
SOLUTION ORGANIZATION
PHASE 2:
DESIGN REVIEW
PHASE 3:
LANGUAGE & LOGIC
PHASE 4:
DATAFLOWS & RULES
PHASE 5:
REPORTING

PHASE 1:
SOLUTION ORGANIZATION

  • Examination of source code file/folder structure
  • Security organization
    • Intermingling of publicly accessible, privately accessible, internally accessible, and internally sensitive files
    • Keys and certificates: public/private
  • Functional organization
    • Code, configuration, development vs. deployment, supporting static content
    • Solution-centric vs component-centric
  • Scalability factors
    • Single-server solutions vs. data center solutions
    • Synchronization vulnerabilities

PHASE 2:
DESIGN REVIEW

During this phase, RedLegg will distinguish the number of pages within the web application using automated web spidering (crawling) tools:

  • Foreign value checks
    • Function/method parameters, Return values
  • Cohesion
    • Grouping similar functionality into units with clearly marked boundaries
  • Coupling
    • Level of interaction between units across unit boundaries
  • Application-level communication protocols
    • Handshakes between client/server
  • Solution domain topology
    • How the solution is hierarchically divided into systems, subsystems, modules, and units

PHASE 3:
LANGUAGE & LOGIC

Review code for language issues that may result in inefficient or insecure code:

  • Type consistency
  • Naming conventions
  • Readability of the code
  • Appropriate level of commenting
  • Depth of nesting
  • Logic patterns – g., if (x == null) return true; else return false; vs. return x == null;
  • Functional programming paradigms – Arrow functions, lambdas, LINQ, and templated classes
  • Scope specifiers – Private, protected, internal, and public:
    • Disposing of unmanaged objects/resources
    • String handling
    • Obvious cut/paste/tweak of code snippets

PHASE 4:
DATAFLOWS & BUSINESS RULES

  • Inbound/Outbound paths and route handlers (client and server)
  • Materialization, validation, verification, transfer, transformation, and persistence of data units, and the different methods for handling due to security risk severity
  • Discretization of business logic for vulnerabilities to due maintenance engineers opening infiltration channels

PHASE 5:
REPORTING

  • Document results.
  • Respond to follow-up questions.
  • PHASE 1:
    SOLUTION ORGANIZATION

    • PHASE 1:
    SOLUTION ORGANIZATION

    • Examination of source code file/folder structure
    • Security organization
      • Intermingling of publicly accessible, privately accessible, internally accessible, and internally sensitive files
      • Keys and certificates: public/private
    • Functional organization
      • Code, configuration, development vs. deployment, supporting static content
      • Solution-centric vs component-centric
    • Scalability factors
      • Single-server solutions vs. data center solutions
      • Synchronization vulnerabilities
  • PHASE 2:
    DESIGN REVIEW

    • PHASE 2:
    DESIGN REVIEW

    During this phase, RedLegg will distinguish the number of pages within the web application using automated web spidering (crawling) tools:

    • Foreign value checks
      • Function/method parameters, Return values
    • Cohesion
      • Grouping similar functionality into units with clearly marked boundaries
    • Coupling
      • Level of interaction between units across unit boundaries
    • Application-level communication protocols
      • Handshakes between client/server
    • Solution domain topology
      • How the solution is hierarchically divided into systems, subsystems, modules, and units
  • PHASE 3:
    LANGUAGE & LOGIC

    • PHASE 3:
    LANGUAGE & LOGIC

    Review code for language issues that may result in inefficient or insecure code:

    • Type consistency
    • Naming conventions
    • Readability of the code
    • Appropriate level of commenting
    • Depth of nesting
    • Logic patterns – g., if (x == null) return true; else return false; vs. return x == null;
    • Functional programming paradigms – Arrow functions, lambdas, LINQ, and templated classes
    • Scope specifiers – Private, protected, internal, and public:
      • Disposing of unmanaged objects/resources
      • String handling
      • Obvious cut/paste/tweak of code snippets
  • PHASE 4:
    DATAFLOWS & RULES

    • PHASE 4:
    DATAFLOWS & BUSINESS RULES

    • Inbound/Outbound paths and route handlers (client and server)
    • Materialization, validation, verification, transfer, transformation, and persistence of data units, and the different methods for handling due to security risk severity
    • Discretization of business logic for vulnerabilities to due maintenance engineers opening infiltration channels
  • PHASE 5:
    REPORTING

    • PHASE 5:
    REPORTING

    • Document results.
    • Respond to follow-up questions.

SECURE CODE REVIEW DELIVERABLES

The deliverable from the Secure Code Review will be a detailed document with sections tailored for different audiences:

  • EXECUTIVE SUMMARY
  • ARCHITECTURE REVIEW
  • DETAILED FINDINGS
  • OBSERVATIONS
  • APPENDICES

EXECUTIVE SUMMARY

This section contains summary information such as numbers of issues identified and critical action items.

ARCHITECTURE REVIEW

Outlines structural findings and feedback regarding the overall structure of the system.

DETAILED FINDINGS

Contains detailed findings referencing source code files and line numbers to provide a fine-grained reference for developers to find and remediate findings:
  • Findings will include a detailed description of the issue found, why it is an issue, and steps for improvement.
  • Remediation steps are typically demonstrated using an actual code snippet from the source code (the ‘From’ code) along with how to specifically change the code (the ‘To’ code).
  • For more complex findings, a single ‘From’ code snippet may be incrementally altered through several steps in order to arrive at a final ‘To’ code snippet.
  • Each iteration is accompanied by text outlining the reasons why the step was taken and why it leads to better, more maintainable code.

OBSERVATIONS

This section is optional and will be included in the deliverable at the discretion of the code reviewer.  If included, it will contain information gathered during the review that may raise questions, concerns, or suggestions about quality that are not necessarily actionable as findings but merit consideration nonetheless.

APPENDICES

Detailed information and evidence used for reference. RedLegg will also place all code review findings into source code management as they were discovered (in real time).

  • EXECUTIVE SUMMARY

    • This section contains summary information such as numbers of issues identified and critical action items.

  • ARCHITECTURE REVIEW

    • Outlines structural findings and feedback regarding the overall structure of the system.

  • DETAILED FINDINGS
    • Contains detailed findings referencing source code files and line numbers to provide a fine-grained reference for developers to find and remediate findings:
    • Findings will include a detailed description of the issue found, why it is an issue, and steps for improvement.
    • Remediation steps are typically demonstrated using an actual code snippet from the source code (the ‘From’ code) along with how to specifically change the code (the ‘To’ code).
    • For more complex findings, a single ‘From’ code snippet may be incrementally altered through several steps in order to arrive at a final ‘To’ code snippet.
    • Each iteration is accompanied by text outlining the reasons why the step was taken and why it leads to better, more maintainable code.
  • OBSERVATIONS

    • This section is optional and will be included in the deliverable at the discretion of the code reviewer.  If included, it will contain information gathered during the review that may raise questions, concerns, or suggestions about quality that are not necessarily actionable as findings but merit consideration nonetheless.

  • APPENDICES

    • Detailed information and evidence used for reference. RedLegg will also place all code review findings into source code management as they were discovered (in real time).

OUR APPROACH

RedLegg is an innovative, global security firm that delivers managed cybersecurity solutions and peace of mind to its clients.

RedLegg’s approach to information security protects the confidentiality, integrity, and availability of critical data based on a sound risk management framework. This approach allows organizations to engage business owners in defining acceptable levels of risk and to participate in the process for evaluating threats.

RedLegg’s ARMEE (Assess, Remediate, Monitor, Educate, Enforce) methodology institutes a lifecycle that allows for an ongoing process to continuously improve the security posture of the organization. This methodology is designed to be portable to all business, legal, regulatory, and security requirements of the organization. It is flexible enough to account for the constant flux in the market place, attack vectors, and protection mechanisms.

ARMEElogo-1

GO DEEPER.

Reach out to our expert staff to dive into your security gaps and to protect your company from breaches.

DISCOVER MY SECURITY RISKS