Your browser is not supported. Please use Chrome, Firefox, Edge or Safari browser. More information

SolutionsCybersecurityApplication development security


Secure by Design: securing the entire development life cycle

These days, application security is a necessity for all type and size of organizations, not just special regulated industries.

Methodology and approach of 4iG: Secure by Design

Application & Development Security is not a goal or a tool, but a process. During this infinite process, we increase the level of security for applications by drafting and enforcing security requirements, by identifying and eliminating risk elements, and by automated and manual security testing of applications.

Already in the development phase, it is important to clarify which security requirements must be met by the end product (e.g.: NIST, ISO, PCI-DSS, or local regulation like Hungarian National Bank (MNB) or Act L, or a special fusion of multiple requirements). This is finalized by defining the development requirements, which later form the basis for testing. It is important to keep in mind that the requirements for the application are in line with the expected risks, i.e. the allocated resources (and thus the costs) are not disproportionate to the business objectives of the system. This approach can prevent many business problems and even personal frustrations.

Architectural and infrastructure requirements add to the full scope (e.g.: use of PKI keys, application identification, SSO, encrypted network traffic), so the security of the improved system must be fully tested already at the design stage.

Security-conscious development behavior is key even when producing a code base that meets the expectations. One of the foundations of a requirements-fulfilling application is security-conscious architecture design. Since in many cases the security specialist and the developer “don’t speak the same language”, special attention should be paid to the wording of the requirements which is understandable and acceptable for the developers.
If necessary, clarification must be improved in several rounds.
The requirements and security parameters of the runtime environments must also be carried out, in addition to the capabilities, characteristics and functionality of on-premises or cloud systems (e.g. the use of AWS's own security capabilities).


  • We undertake the audit of system designs and the audit of applications and systems developed by others.
  • For applications in regulated industries, we also support prior checking of regulatory compliance levels with highly qualified and experienced 4iG experts.
  • The security of the code or system elements is verified by automated or manual testing, the tools of which are static and dynamic code-scanner applications, as well as ethical hacker experts.


Applications store, manage, and transmit business data, but software vulnerabilities face business risks. Our Source Code Analysis (SCA) solution can support all participants in the development process (developers, programmers, quality assurance experts, testers, security auditors, etc.) in identifying and correcting security flaws in the source code and allow for post-repair verification of detected errors.

Technologies used by 4iG:

  • Acunetix
  • Qualys


A security-conscious approach to development has never been more important. Nowadays, it is not uncommon to operate programs and systems with continuous delivery (CI-CD), so they are constantly changing. This is an extremely powerful, flexible, and effective method, but it also brings new risks that we need to address with our security practices. In order to do this properly, security must always be a priority in development and implementation.

Continuous delivery also gives us new tools to manage the risks that arise: version control, multiple reviews and automated testing; the proper use of all these can improve security during development.

8 principles for secure development and deployment:

  1. Safe development is in everyone's interest.
  2. Keep your security knowledge up to date!
  3. Develop a clean and maintainable code!
  4. Secure the development environment!
  5. Protect the storage locations of the codes (repository)!
  6. Ensure the development and installation processes are standardized and safe.
  7. Test security constantly!
  8. Plan ahead for security flaws! How do you react to them when they are identified?


Part of this service, and at the request of our customers, we detect current vulnerabilities in their existing system or a software, services or even a website to be introduced, and we propose methods to eliminate these vulnerabilities.

During the test, our specialists use international methodologies and automated and manual tests to identify the vulnerabilities that can be detected. In such a complex vulnerability test, automated testing is around 30%, and manual takes up 70% of the testing process. If vulnerability is identified, it is manually validated to fully exclude so-called ‘false-positive’ results. For the penetration test, the PTES2 methodology is followed, while the main methodology for vulnerability testing of web applications is OWASP3. In the case of OWASP, we not only rely on the top 10 requirements of OWASP, but also use a significantly more complex test method based on OWASP. In web scans, for automated testing, we use the world's leading Acunetix web vulnerability tester, and Nessus on the network side, while for manual testing OWASP Zed Attack Proxy (ZAP), BurpSuite Pro, and other open-source tools are used.

Whether it is a network or web application test, our experts select the methods to each authorization level (Black-Box, Gray-Box, White-Box) based on consultation with the customer while considering a broad set of needs.

Having completed the test, we provide a complex report in which the identified vulnerabilities are ranked and organized according to their risk classification. Vulnerability details include a brief description (reference), vulnerability parameters, and suggestions for correction. These can be used for the smooth correction of detected errors.

Once the identified vulnerabilities have been corrected, it is possible to carry out a so-called review test, in which we no longer retest the entire application, but only recheck the previously identified vulnerabilities.

After the initial period, we can perform ongoing continuous Vulnerability Management services on a regular basis (monthly; quarterly; annual).