In the modern world, software is everywhere. Software houses and programming enthusiasts produce millions of lines of code that other specialists use transparently. Maintaining a high level of security for such software snippets is essential, but unfortunately, this level of security is not largely met.

Nowadays, whether an application consists of just a few lines of code or is a big and complex program, it most likely relies on additional libraries. Those dependencies facilitate the developer’s work, speed up the creation of a product, and significantly enlarge the code base… as well as the number of bugs. Also, considering that code is written by people – and no one is infallible – it’s impossible to have an entirely bug-free piece of software. The code review process helps to eliminate software bugs, but the outcome is also prone to human error.

لماذا يُعد تدقيق الكود بحثاً عن الثغرات أمراً مهماً؟

الـ اختبار الاختراق is a time-limited operation, so finding all the security issues during the process is almost impossible. Due to limited budgets, companies often take the black box approach, auditing software without prior knowledge about how the system works. Black box testing further limits the likelihood of finding security bugs. 

حتى فريق من متخصصي الأمن السيبراني لن يتمكن من اكتشاف كل مشكلة. فالوقت المتاح لإجراء اختبارات الصندوق الأبيض محدود، لذا قد تبقى بعض الأخطاء دون اكتشاف.

لسوء الحظ، لا يقيّد مجرمو الأمن السيبراني الوقت أو المال. فلديهم موارد غير محدودة لتحليل البرمجيات واكتشاف الثغرات الأمنية التي يمكنهم استغلالها.

لمنع هجوم إلكتروني ناجح، ينبغي إجراء مراجعة أمنية للشيفرة البرمجية. وهي عملية فحص الشيفرة المصدرية للكشف عن الثغرات والعيوب الأمنية وإزالتها.

يمكن إجراء التقييم على النحو التالي:

  • يدويًا بواسطة شخص،
  • بطريقة آلية، باستخدام أدوات مراجعة أكواد الأمان،
  • أو من خلال الجمع بين هذين النهجين.

مراجعة الكود الأمنية مقابل مراجعة الكود

While regular code reviews focus on the quality of the code, security code reviews focus on its secure aspects, like string concatenation of database operations or authentication configuration.

A security bug is a specific type of software flaw that allows an action, that the application’s author didn’t intend, to take place. For instance, the wrong application parameter handling can lead to an attacker injecting additional SQL queries and retrieving sensitive data, like passwords, from the database.

كيفية إجراء مراجعة أمنية للشيفرة البرمجية

لا توجد طريقة منهجية لإجراء مراجعة أمنية للشيفرة البرمجية، على الرغم من إمكانية القيام بذلك بمساعدة معايير معروفة مثل:

  • OWASP TOP 10،
  • قائمة Mitre Top 25 لأخطر نقاط الضعف في البرمجيات،
  • PCI-DSS،
  • أو HIPPA.

يجب أن يكون كل مبرمج على دراية بالمعايير وأن يطّلع على الأقل على ورقة الغش الخاصة بأهم عشر ثغرات في OWASP TOP 10. وبالطبع، ينبغي له أيضاً اتباع معايير الأمان الداخلية للمؤسسة.

إذا تم تطبيق هذه المعرفة، يمكن أن تزيد من مستوى أمان الكود في مرحلة التطوير.

مراجعة أكواد الأمان الآلية

بصرف النظر عن فحص الكود يدويًا، يمكن إجراء التدقيق باستخدام أدوات مراجعة الكود الأمني الآلية. يمكن تقسيمها إلى مجموعتين:

  • SAST – اختبار أمان التطبيقات الساكن،
  • DAST – اختبار أمان التطبيقات الديناميكي.

اختبار أمان التطبيقات الساكن (SAST)

SASTtools are simple scanners with rules that aim to find the code’s patterns. The effectiveness of this approach depends on the quality of the set rules. SASTtools are language-dependent, so if the software is written in a rare programming language, in some cases the automated analysis cannot be performed. Regarding the دورة حياة تطوير البرمجيات الآمنة (S-SDLC) إطار العمل، ينبغي تفعيل تحليل SAST أثناء عملية بناء التطبيق لاكتشاف المشكلات الأمنية في أقرب وقت ممكن.

اختبار أمان التطبيقات الديناميكي (DAST)

DAST tools are independent of the technology stack. They test and exploit the application during its runtime. The DASTtools don’t need to access the source code, which is a significant advantage in some situations. Their main drawback is that they can’t find all the security flaws; what’s more, to interpret the results, technical security knowledge is required.

أدوات لمراجعة الكود الأمني الآلية

Tools can also help to find “low-hanging fruit” when dealing with large amounts of code. Most of them are grep-like tools which look for a predefined sets of rules, keywords, or technology-specific functions. For instance, (Java Spring framework case): find the following piece of code: “csrf().disable()”; if this code is found, report this situation as a security issue as the anty Cross-Site Request Forgery mechanism is disabled.

SonarQube or semgrepهما مثالان؛ كلاهما منصات مفتوحة المصدر لتحليل الكود الثابت للعثور على الأخطاء واكتشاف الثغرات الأمنية في التبعيات.

There are also tools that offer a more advanced approach enabling the use of internal language, writing advanced rules and querying the code. They can even handle queries such as “find all the methods” (while in object-oriented programming, “a method” is another term for a function), where code responsible for authorisation is not present. 

A greater range of possibilities also requires greater domain skills. To write such queries, one should have a certain degree of security knowledge, that may be regulated by the code writing style. For external auditors this approach is prone to false positives and false negatives. However, it can be an excellent solution for engineers that are part of an internal development team.

مراقبة التبعيات

As mentioned, dependencies are an integral part of the software. Usually, libraries are more extensive than the software itself, and using them expands the threat surface as well. Reviewing the code to ensure the security of third-party dependencies is barely possible, as the time for delivering the product is always strictly limited. Fortunately, tools like OWASP Dependency Check or npm audit يمكنها معالجة قيد الوقت. بفضل العديد من الباحثين الذين يبلغون عن الثغرات، تحتفظ هذه الأدوات دائمًا بقائمة محدثة بأكثر مشكلات الأمان شيوعًا وحداثة.

مراجعة يدوية للشيفرة الأمنية

The main advantage of a manual security code review is that it’s carried out by an auditor who understands the business logic and validation, and can find vulnerabilities in it. This kind of code review is performed with the use of an IDE tool (integrated development environment). Depending on which language the audited application is written in, usually VS Code or IntelliJكافية.

من أين يجب أن تبدأ مراجعة الكود الأمني اليدوية؟

To perform a manual security code review, the best and simplest approach would be to read the code from the beginning. But in most cases, there is no such thing as one point where the program begins. 

For instance, applications designed in the MVC principle can consist of tens of controllers with hundreds of actions, each of which can be treated as “the beginning”. In that case, the code can be read from the action (controller level) through the service layer into the model layer, where database operations are stored. That approach makes sure that every API method is checked. 

Another strategy is to read the code from the bottom (database layer) to the top (controller layer). In the case of SQL injection vulnerability, it will be easier to identify affected endpoints or methods. 

كما يمكنك البحث عن وظائف خاصة بالتكنولوجيا قد تؤدي إلى نقاط ضعف – مثلالنظام() أوshell_exec() في PHP، أوتقييم(), setInterval() في JavaScript – وتحليل المسار أو التدفق داخل الكود لتحديد ما إذا كان من الممكن حقن كود ضار في الدوال.

تعتمد الاستراتيجية على عدة عوامل، مثل عدد أسطر الكود (LoC)، والوقت الممنوح للمراجعة، أو مجموعة التقنيات.

ملفات التكوين والبيانات الحساسة

Another critical step of a code security review is checking the configuration files. In many cases – especially in non-public code repositories – configuration files contain sensitive data like passwords, API keys, or other types of secrets. Sensitive data stored in the code repository is treated as compromised; thus, secrets, passwords, or API keys should be re-generated and stored in secure places, like vaults. Configuration files must contain only placeholders for values, not values themselves.

In case of vulnerability identification, confirming the finding and exploiting the issue in the application runtime is a good practice. There are cases where, through reading the code, an auditor identifies a security issue, but the framework’s security mechanisms apply a protection layer so, as a result, the flaw can’t be exploited.

حافظ على أمان تطبيقك

Reviewing software code is a challenging task. Still, by doing it methodically with the support of automated tools, it is possible to cover more threat landscapes, ultimately having more impact than in any other type of security audit.

إذا كنت ترغب في ضمان مستوى عالٍ من الأمان في تطبيقك، فاتصل بنا. سنناقش معًا الاحتياجات ونطاق تدقيق الأمان. ستجد هنا مزيداً من المعلومات حول كيف يمكننا مساعدتك.

A security code review is a systematic examination of source code specifically designed to identify security vulnerabilities and flaws. It differs from a standard code review, which focuses on quality, architecture, and correctness. Security reviews look for exploitable weaknesses including authentication issues, injection vulnerabilities, hardcoded secrets, and insecure use of dangerous functions.

Penetration tests operate under time and budget constraints, which means they cannot cover all possible vulnerabilities in a system. Attackers, by contrast, have unlimited time to analyse software. Regular security code review provides a systematic, ongoing layer of defence that complements the point-in-time findings of a penetration test.

Manual review involves security auditors examining code using IDE tools, tracing logic flows, and understanding business context to identify vulnerabilities that automated tools miss. Automated approaches include SAST (Static Application Security Testing), which uses pattern matching on source code, and DAST (Dynamic Analysis Security Testing), which tests running applications. The most effective programmes combine both.

High-priority areas include configuration files that may contain hardcoded passwords or API keys, technology-specific dangerous functions (such as PHP’s system() or JavaScript’s eval()), SQL query construction, authentication and session management logic, and third-party dependency versions. Dependencies are a frequently overlooked vector; known vulnerabilities in outdated libraries are a common source of exploitable weaknesses.

The primary reference frameworks are OWASP TOP 10 (the most critical web application security risks), MITRE Top 25 (the most dangerous software weaknesses), and industry-specific standards like PCI-DSS for payment systems and HIPAA for healthcare applications. These frameworks provide a consistent, recognised baseline for what a security review should cover.

arrow_circle_right جدول المحتويات

Piotr Izak Senior Cybersecurity Pentester

Piotr Izak

مختبر اختبار اختراق الأمن السيبراني الأول

مقالات ذات صلة