Hello, Habr! My name is Artem, and I'm the head of the technical expertise center for security analysis at AKTIV.CONSULTING . Today, I'd like to discuss software vulnerability detection during operation and explore whether this is a basic minimum or a luxurious maximum. We'll focus on Process 24 of GOST R 56939-2024 for the development of secure software (BRPO, RBPO, DevSecOps).
Three whales of the BRPO (RBPO)
To begin, let's review the three main methods of software vulnerability analysis: static, dynamic, and compositional. Static analysis involves analyzing source code (white-box testing). Dynamic analysis is a classic pentest, where we test a running application in a black or gray box. Compositional analysis scans and searches for vulnerabilities in the components being used, which allows us to expand the attack surface.
But simply knowing these methods isn't enough. It's important to understand who will use them in practice and how, as well as whether automated vulnerability scanners or human experts are better. Let's find out.
Automated and Manual Search: How to Conduct Software Vulnerability Analysis
In my opinion, automated vulnerability scanning is a basic, necessary minimum in today's world. Just three or four years ago, such a statement would have been unacceptable to me as a penetration tester, but the world has changed. Today, vulnerability scanners have matured significantly, learned to find real problems, and cover a vast range of tasks. In a previous article on Habr, I compiled a selection of such scanners. Any penetration tester can use them when auditing infrastructure and the external perimeter.
However, precise tool setup is essential, as improper or excessive use can cause damage to your own system. Scanners should be used carefully, with careful selection of parameters, or left to professionals.
Ideally, automated vulnerability scanning should result in two components:
1. Pentest Continuous
Regular automated scanning of the system or software, generating a report that shows the dynamics (what new vulnerabilities have appeared, what ports have opened, what has changed in the software, etc.)
2. Monitoring (SOC)
Monitoring both new vulnerabilities and those that can be used to attack your software and information systems provides an up-to-date threat landscape in real time.
While we consider automated vulnerability scanning a necessary minimum, manual vulnerability scanning can be considered a luxury. Qualified specialists are scarce, and their work is expensive. Such experts are hired not for show, but for genuine software security testing.
From my experience, I can say that such specialists often find what was missed even by clients who are seriously committed to information security. It's important to remember that no system is completely secure (unless, perhaps, a computer in a bunker without internet access). A penetration tester's experience, critical thinking, and ingenuity allow them to construct attack chains that ultimately achieve the desired results in accessing information or a system.
Software Vulnerability Analysis Steps: How the OWASP TOP-10 Can Help
The vulnerability testing process can be divided into four key stages:
Intelligence
At this stage, it is important to understand what we are attacking and find all potential entry points, that is, to maximize the attack surface.
Vulnerability Scanning
After receiving the reconnaissance results, we search for vulnerabilities based on software versions, the Common Vulnerabilities and Exposures (CVE) database, and personal experience.
Exploiting vulnerabilities and conducting attacks
Here, we verify the vulnerabilities found and attempt to exploit them, specifically by penetrating deeper into the system, expanding to adjacent nodes, escalating privileges, etc.
Report
This is a crucial stage, the value of which lies in its recommendations. The report includes both general recommendations for improving software and information system security, as well as specific measures for each vulnerability identified.
To describe the main vulnerabilities, let's use the OWASP TOP-10 . Although this list of vulnerabilities is created for the web, all the problems described are common to most types of software:
How to implement a vulnerability scanning process
Implementing a vulnerability scanning process during exploitation is a complex task. One of the main challenges is communicating the new responsibilities and the need for these actions to developers. The question arises: who should be entrusted with the implementation work? There are two main approaches:
First, a Security Champion is a member of the development team who is passionate about security and passionate about it. They are trained and implement security processes during the software development stage, striving to minimize vulnerabilities. Second, consulting, i.e., engaging external penetration testers.
What's the difference between a Security Champion and a penetration tester? They have fundamentally different mindsets. A penetration tester enjoys solving puzzles, and for them, finding vulnerabilities becomes a quest with destructive elements (find, break, penetrate). A Security Champion, on the other hand, is a builder. Their job is to create a kind of "fortress" and prevent vulnerabilities during the development stage.
Neither approach is ideal. Human error cannot be ruled out, so I recommend using a combination of methods. Let the Security Champion build the processes within the company, and at the final stage, external pentesters will look for any overlooked areas, fine-tune the system, and share their experience with the in-house specialist.
Case studies
In conclusion, I will give a few striking and illustrative examples from my practice.
Case 1. Implementation of a BRPO (RBPO) at a major information security vendor
The client initiated the implementation of GOST-compliant processes, recognizing that the standard was not yet mandatory. Despite this, quite a long time elapsed between the initial task and the creation of the working group. This case demonstrated that even when the business is ready, implementation requires patience and time to resolve organizational issues.
Case 2. Implementing secure software development after an incident
A major vendor began implementing BRPO (RBPO) processes only after a real incident. The situation forced the company to rethink its approach to security and demonstrated the importance of information security. However, it's better not to wait for such an incident to occur; instead, take the first example.
Case 3. Penetration testing of a trading system
While testing a large trading system, we encountered an interesting situation. During the first scan and analysis, not a single automated scanner found any vulnerabilities—not high, medium, or low. The client was confident in their protection and was convinced we wouldn't find anything. However, during the manual investigation, I discovered about 10 medium and low-level vulnerabilities. Individually, they seemed harmless, but the combination of five of them allowed us to build a full-fledged attack vector and completely compromise the information system. This case clearly demonstrates the importance of paying attention to vulnerabilities of any risk level and responsibly addressing them.
Result
Automated vulnerability scanning is now a basic, necessary minimum, and it should be properly configured and running on a consistent basis. However, relying solely on scanners is not recommended: manual scanning by experienced specialists remains a luxury, allowing for the discovery of flaws. The optimal solution is a combination of regular automated scanning and the involvement of penetration testers for a thorough vulnerability analysis. This comprehensive approach will provide the most accurate assessment of your software's security. A checklist for security analysis can be found here .
Three whales of the BRPO (RBPO)
To begin, let's review the three main methods of software vulnerability analysis: static, dynamic, and compositional. Static analysis involves analyzing source code (white-box testing). Dynamic analysis is a classic pentest, where we test a running application in a black or gray box. Compositional analysis scans and searches for vulnerabilities in the components being used, which allows us to expand the attack surface.
But simply knowing these methods isn't enough. It's important to understand who will use them in practice and how, as well as whether automated vulnerability scanners or human experts are better. Let's find out.
Automated and Manual Search: How to Conduct Software Vulnerability Analysis
In my opinion, automated vulnerability scanning is a basic, necessary minimum in today's world. Just three or four years ago, such a statement would have been unacceptable to me as a penetration tester, but the world has changed. Today, vulnerability scanners have matured significantly, learned to find real problems, and cover a vast range of tasks. In a previous article on Habr, I compiled a selection of such scanners. Any penetration tester can use them when auditing infrastructure and the external perimeter.
However, precise tool setup is essential, as improper or excessive use can cause damage to your own system. Scanners should be used carefully, with careful selection of parameters, or left to professionals.
Ideally, automated vulnerability scanning should result in two components:
1. Pentest Continuous
Regular automated scanning of the system or software, generating a report that shows the dynamics (what new vulnerabilities have appeared, what ports have opened, what has changed in the software, etc.)
2. Monitoring (SOC)
Monitoring both new vulnerabilities and those that can be used to attack your software and information systems provides an up-to-date threat landscape in real time.
While we consider automated vulnerability scanning a necessary minimum, manual vulnerability scanning can be considered a luxury. Qualified specialists are scarce, and their work is expensive. Such experts are hired not for show, but for genuine software security testing.
From my experience, I can say that such specialists often find what was missed even by clients who are seriously committed to information security. It's important to remember that no system is completely secure (unless, perhaps, a computer in a bunker without internet access). A penetration tester's experience, critical thinking, and ingenuity allow them to construct attack chains that ultimately achieve the desired results in accessing information or a system.
Software Vulnerability Analysis Steps: How the OWASP TOP-10 Can Help
The vulnerability testing process can be divided into four key stages:
Intelligence
At this stage, it is important to understand what we are attacking and find all potential entry points, that is, to maximize the attack surface.
Vulnerability Scanning
After receiving the reconnaissance results, we search for vulnerabilities based on software versions, the Common Vulnerabilities and Exposures (CVE) database, and personal experience.
Exploiting vulnerabilities and conducting attacks
Here, we verify the vulnerabilities found and attempt to exploit them, specifically by penetrating deeper into the system, expanding to adjacent nodes, escalating privileges, etc.
Report
This is a crucial stage, the value of which lies in its recommendations. The report includes both general recommendations for improving software and information system security, as well as specific measures for each vulnerability identified.
To describe the main vulnerabilities, let's use the OWASP TOP-10 . Although this list of vulnerabilities is created for the web, all the problems described are common to most types of software:
- A01:2025 Access Control Violation
- A02:2025 Incorrect security system configuration
- Both of these problems are somewhat similar and are often caused by incorrect software settings.
- A03:2025 Software Supply Chain Disruptions
- Since any software consists of several components, infection of one of them during the development process can lead to vulnerability of the software as a whole.
- A04:2025 Cryptographic Failures
- This is about errors in encryption and SSL settings.
- A05:2025 Malware Injection
- A06:2025 Unsafe design
- A07:2025 Authentication failures
- Incorrect configuration or ability to bypass login mechanisms.
- A08:2025 Software or data integrity failures
- A09:2025 Security logging and alerting failures
- If a failure occurs or security logs are configured incorrectly, attack events may go undetected.
- A10:2025 Incorrect handling of exceptional conditions
How to implement a vulnerability scanning process
Implementing a vulnerability scanning process during exploitation is a complex task. One of the main challenges is communicating the new responsibilities and the need for these actions to developers. The question arises: who should be entrusted with the implementation work? There are two main approaches:
First, a Security Champion is a member of the development team who is passionate about security and passionate about it. They are trained and implement security processes during the software development stage, striving to minimize vulnerabilities. Second, consulting, i.e., engaging external penetration testers.
What's the difference between a Security Champion and a penetration tester? They have fundamentally different mindsets. A penetration tester enjoys solving puzzles, and for them, finding vulnerabilities becomes a quest with destructive elements (find, break, penetrate). A Security Champion, on the other hand, is a builder. Their job is to create a kind of "fortress" and prevent vulnerabilities during the development stage.
Neither approach is ideal. Human error cannot be ruled out, so I recommend using a combination of methods. Let the Security Champion build the processes within the company, and at the final stage, external pentesters will look for any overlooked areas, fine-tune the system, and share their experience with the in-house specialist.
Case studies
In conclusion, I will give a few striking and illustrative examples from my practice.
Case 1. Implementation of a BRPO (RBPO) at a major information security vendor
The client initiated the implementation of GOST-compliant processes, recognizing that the standard was not yet mandatory. Despite this, quite a long time elapsed between the initial task and the creation of the working group. This case demonstrated that even when the business is ready, implementation requires patience and time to resolve organizational issues.
Case 2. Implementing secure software development after an incident
A major vendor began implementing BRPO (RBPO) processes only after a real incident. The situation forced the company to rethink its approach to security and demonstrated the importance of information security. However, it's better not to wait for such an incident to occur; instead, take the first example.
Case 3. Penetration testing of a trading system
While testing a large trading system, we encountered an interesting situation. During the first scan and analysis, not a single automated scanner found any vulnerabilities—not high, medium, or low. The client was confident in their protection and was convinced we wouldn't find anything. However, during the manual investigation, I discovered about 10 medium and low-level vulnerabilities. Individually, they seemed harmless, but the combination of five of them allowed us to build a full-fledged attack vector and completely compromise the information system. This case clearly demonstrates the importance of paying attention to vulnerabilities of any risk level and responsibly addressing them.
Result
Automated vulnerability scanning is now a basic, necessary minimum, and it should be properly configured and running on a consistent basis. However, relying solely on scanners is not recommended: manual scanning by experienced specialists remains a luxury, allowing for the discovery of flaws. The optimal solution is a combination of regular automated scanning and the involvement of penetration testers for a thorough vulnerability analysis. This comprehensive approach will provide the most accurate assessment of your software's security. A checklist for security analysis can be found here .
