Daniil Kamoltsev, Security Vision
Introduction
As an information security engineer, I periodically have to work with tools that scan code for vulnerabilities. This experience made me think: what if we approach code security proactively – not to fix errors after the fact, but to find and prevent them at every stage of the program's lifecycle?
Imagine: You have just finished writing a complex module for a new application. The code is clean, the logic is impeccable, all the tests pass. You feel like a real architect of the digital world. Run the program, and yes, it works! It would seem that the task has been completed successfully.
However, this code, which is flawless in all respects, may harbor invisible "hatches". No, not bugs in our usual understanding, but vulnerabilities, the presence of which can turn into a real disaster if left unattended. It's like building a luxurious castle with powerful walls, but forgetting to lock the secret gate in the very foundation. Unfortunately, in the digital world, such "gates" rarely remain just a hypothetical gap in protection. They turn into real attack vectors capable of causing damage on a global scale.
From a "secret gate" to a global threat
The story of the attack on SolarWinds is not a movie script, but a harsh reality that clearly demonstrates the consequences of just one vulnerability in the software supply chain. In early 2020, hackers introduced malicious code into the Orion software platform, and this single "gateway" opened access to the networks of thousands of companies around the world, including US government agencies and large IT corporations [1].
The attack was particularly insidious because the attackers compromised the software update process, a mechanism that users traditionally consider secure and trusted. The malicious code was distributed as an official update, which allowed it to freely enter corporate networks under the guise of legitimate software. According to a report by the US Cybersecurity and Infrastructure Security Agency (CISA), the attackers demonstrated high operational efficiency and careful attack preparation. They used sophisticated methods to avoid detection, including disguising their malicious activities as legitimate Orion traffic and using third-party infrastructures, which seriously hampered the timely detection of the threat [2].
The devastating "domino effect" of such incidents manifests itself in several aspects:
· A chain reaction of compromise: by penetrating a vulnerability in one product, attackers gain access to the data and systems of multiple organizations.;
· loss of trust: the reputation of not only the developer company suffers, but also of all organizations using compromised software.;
· Economic losses: direct losses from system downtime and incident investigation costs are estimated in the millions of dollars. According to IBM, the average total cost of a data breach in 2023 reached a record 4.45 million US dollars [3].
Correcting such errors in a finished product can cost 20-100 times more expensive than preventing them at the design and code writing stage [1]. A study conducted by the IBM Institute of System Sciences showed that the cost of correcting a defect found during the operational phase can be 100 times higher than the cost of eliminating it at the design stage [4].
Moreover, according to the Veracode "State of Software Security" report, 76% of applications contain at least one vulnerability in open source components at the time of the first scan [5, 6]. This confirms that the problem of software supply chain security is widespread.
At the same time, as modern research shows, the traditional approach to security as a one-time audit at the end of development turns out to be ineffective. Teams are beginning to perceive security as a barrier, especially when inspections reveal many problems in the final stages of the project, and fixes require redesign of architectural solutions [7]. The key principle of effective implementation of security is its integration into daily development processes through automation of checks, provision of contextual recommendations and embedding in familiar developer tools, which reflects the approach of SSDLC (Secure Software Development Life Cycle) – a secure software development life cycle.
Russian information security standards also pay special attention to this issue. GOST R 56939-2024 requires developers to perform compositional analysis and dependency management to identify vulnerabilities in borrowed components [8]. And GOST R 71207-2024 sets strict requirements for regular static code analysis specifically to find critical errors that can lead to information security violations [9].
That is why a developer should worry about security not after the project is completed, but from the very first line of code. Every developer today is not just a creator of functionality, but also the first line of defense in global cybersecurity. Practice shows that the prevention of vulnerabilities in the early stages of development is not only cost-effective, but also critically important for national and corporate security.
Five lines of defense of your "digital castle"
To reliably protect your creation, you need to build several lines of defense at all stages of construction. Imagine a perfectly defended fortress:
· Design and architecture (Drawings and plans). You build security into the structure itself, anticipating threats even before pouring the foundation.
· Code security control (Inspection of materials). You check each brick (line of code) and all ready-made blocks (third-party libraries) for strength and hidden defects.
· Infrastructure control (Construction site control). You ensure a safe and reproducible build process where every tool is tested.
· Security of deployment (Installation of gates and grilles). You set up the final lines of defense just before letting the residents in.
· Runtime security and monitoring (Post Service). You continuously observe the life of the castle, ready to repel any attack.
Let's look at which "tools and techniques" help us at each of these milestones.
Defender's arsenal: SAST, DAST, SCA, IAST and others
To securely protect your application, you need a whole arsenal of tools, each of which plays a role at different stages of the lifecycle. Let's take a closer look at them.
SAST (Static Analysis) – "Drawing Reviewer"
What is he doing?
- carefully examines the source code, bytecode, or binary files without launching the program. This is similar to the work of an experienced architect who checks drawings for design errors, such as structural weaknesses or inconsistencies with standards, even before construction begins [1]. SAST tools work on a "white-box" principle (with access to the code), analyzing data paths and identifying vulnerabilities in the application logic itself.
When to use it?
- at the stage of code security control, ideally directly during code writing in the IDE or at the stage of creating a pull/merge request. This allows developers to receive feedback in near real-time and instantly fix issues such as SQL injections, XSS, buffer overflows, and memory issues [10].
According to the standard: GOST R 71207-2024 explicitly prescribes static analysis as a mandatory practice. The standard requires its regular implementation (at least once every 10 working days) and sets strict quality criteria for analyzers, including the classification of critical errors and the acceptable percentage of false positives [9].
DAST (Dynamic Analysis) – "Strength Tester"
What is he doing?
- tests the application in the execution state from the position of an external intruder, without having access to the source code ("black-box" testing). The DAST scanner actively attacks the application through its external interfaces (web forms, APIs, query parameters), trying to find vulnerabilities that manifest themselves only during operation [1]. According to OWASP, DAST is particularly effective in identifying issues such as configuration flaws, authentication and authorization issues, as well as vulnerabilities that depend on application status and runtime [11]. The strength of this approach is the ability to detect what is clearly not visible in the program code and assess security from the point of view of the end user and the attacker.
When to use it?
- at the stage of infrastructure control (CI). DAST is indispensable for checking ready-made assemblies in test environments as close as possible to production, where you can assess the security of the entire application assembly, including server settings.
SCA (Component Analysis) – "Supplier Verification"
What is he doing?
- automatically identifies all third-party libraries and open source components used in the project, creates a complete Bill of Materials (BOM). According to Synopsys, SCA provides full visibility of all open source components in an application by monitoring license compliance, security vulnerabilities, and outdated versions. This allows developers and security specialists to manage the risks associated with the use of open source software throughout the entire lifecycle of application development [12].
When to use it?
- at the Infrastructure Control (CI) stage, integrating dependency scanning into the build process. It is also recommended to perform it regularly, as vulnerability databases are constantly being updated.
According to the standard: GOST R 56939-2024 requires developers to manage software dependencies and perform compositional analysis to identify vulnerabilities in borrowed components, which makes SCA not just a recommendation, but an essential element of the secure software development process [8].
IAST (Interactive Analysis) – "Internal Agent"
What is he doing?
- this is a hybrid approach combining the advantages of SAST and DAST [13]. IAST uses a lightweight agent embedded in the tested application itself (often through code instrumentation). This agent constantly monitors code execution during automated tests (for example, unit or API tests) or even manual testing. He has access to both the code and the operations performed, which allows him to accurately identify vulnerabilities and point to a problematic line of code, minimizing false positives [14]. The strong point of the approach is the high detection accuracy and the ability to integrate into the testing process without requiring a separate scanning stage.
When to use it?
- at the testing stage, ideally within the framework of automated test runs. IAST provides "inside-out" visibility of the application under load.
Fuzzing – "Stress test for unpredictability"
What is he doing?
- this is an automated technique that finds vulnerabilities by entering a huge amount of random, unexpected or incorrectly formed data into an application. Fuzzers come in different types: "dumb" (completely random data) and "smart" (analyzing the structure of input data to generate more efficient test cases) [15]. They monitor whether any of the inputs lead to a crash, memory leak, or other abnormal behavior [16].
When to use it?
- at the stages of infrastructure control and in-depth testing. It is especially effective for testing parsers, file handlers, network protocols, and APIs.
According to the standard: fuzzing testing is recognized as an official type of program research work in GOST R 56939-2024, which emphasizes its importance in a comprehensive software security assessment ([8], sections 3.22, 5.11). The standard defines fuzzing testing of a program as "a type of program research work based on the transfer of random or specially generated data to the program. input data other than the data provided by the program's algorithm." This formalizes this method as a mandatory element of comprehensive security testing, along with static and dynamic analysis.
Winning strategy: Integrating security into the process
One tool will not make your castle impregnable. An integrated approach is needed:
· The "Shift-Left” mentality. Start thinking about security not before release, but at the design stage. This means "shifting" all checks as far to the left as possible, to the beginning of the lifecycle [1].
· Combine the methods. SAST finds flaws in the source code, DAST checks the running application, and SCA monitors vendors. Use them together.
· Automate it. Integrate security checks into your CI/CD so that they become an integral part of the process rather than a chore.
· Constantly learn. Threats are changing, and the developer, like any professional, must constantly improve his security skills ([8], section 5.2).
Conclusion: from architect to defender
Your role as a developer today goes beyond just creating functional code. You are not only an architect, but also the main defender of your digital castle! Each line of code is not just a command for the machine. This is a potential entry point or barrier to an attacker.
By investing time and resources in security from the planning stage of the project, you not only avoid future headaches. You are creating not just a working product, but a reliable, high-quality and trustworthy product. In a world where a single "secret gate" can cost millions, it is the developer who holds the key to the main gate. Make sure that only you have this key.
List of literature
1. The-Basics-of-Secure-Software-Development-SSDLC [Electronic resource]. – Condition Zebra, 2022. – 36 с. – URL: https://condition-zebra.com/wp-content/uploads/2022/08/The-Basics-of-Secure-Software-Development-SSDLC.pdf
2. Alert (AA20-352A) Advanced Persistent Threat Compromises of U.S. Government Agencies, Critical Infrastructure, and Private Sector Organizations [Electronic resource] / Cybersecurity and Infrastructure Security Agency (CISA). – 2020. – URL: https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a
3. Cost of a Data Breach Report 2023 [Electronic resource] / IBM Security. – 2023. – URL: https://www.ibm.com/reports/data-breach
4. The Economic Impacts of Inadequate Infrastructure for Software Testing [Electronic resource] / National Institute of Standards and Technology (NIST). – 2002. – URL: https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf
5. State of Software Security v12: Don't become complacent, but we've come a long way [Electronic resource] Veracode. – 2022. – URL: https://www.developer-tech.com/news/state-of-software-security-v12-dont-complacent-but-come-long-way/
6. 10 Stats on the State of Vulnerabilities and Exploits [Electronic resource] / Bitdefender. – 2023. – URL: https://www.bitdefender.com/en-us/blog/businessinsights/10-stats-on-the-state-of-vulnerabilities-and-exploits/
7. Secure development without barriers: how to build an SSDLC that actually works // Habr, Блог компании Security Vision [Electronic resource]. – 2025. – URL: https://habr.com/ru/companies/securityvison/articles/928110/
8. GOST R 56939-2024 Information security. Development of secure software. General requirements. Moscow: Russian Institute of Standardization, 2024. 35 p.
9. GOST R 71207-2024 Information security. Development of secure software. Static analysis of software. General requirements. Moscow: Russian Institute of Standardization, 2024. 20 p.
10. What is Static Application Security Testing (SAST?) [Electronic resource] / Synopsys. – URL: https://www.synopsys.com/glossary/what-is-sast.html
11. Dynamic Application Security Testing (DAST) [Electronic resource] / OWASP. – URL: https://owasp.org/www-project-devsecops-guideline/latest/02b-Dynamic-Application-Security-Testing
12. What is Software Composition Analysis (SCA)? [Electronic resource] / Synopsys Black Duck. – URL: https://www.blackduck.com/glossary/what-is-software-composition-analysis.html
13. Application security testing methods [Electronic resource] / SecurityLab. – 2022. – URL: https://www.securitylab.ru/analytics/533602.php
14. Interactive Application Security Testing (IAST) [Electronic resource] / OWASP DevSecOps Guideline. – URL: https://owasp.org/www-project-devsecops-guideline/latest/02c-Interactive-Application-Security-Testing
15. What is Fuzz Testing (Fuzzing)? Explained with Examples [Electronic resource] / Testfully. – 2024. – URL: https://testfully.io/blog/fuzz-testing/
16. OWASP Fuzzing Guide [Electronic resource] / OWASP. – URL: https://owasp.org/www-community/Fuzzing
