And I’ll start with the main thing: don’t take information security lightly. I hear two phrases very often. The first is «we are not interesting to attackers.» But any business is always at risk. An incident means loss of profit, significant expenditure of resources for recovery, and reputational risks. Reputation is hard to build, but easy to lose. If you look globally, the picture is different. You work and pay taxes that go to support the Armed Forces of Ukraine and other areas. An incident that led to a reduction in profits affects taxes. Accordingly, the fewer taxes, the smaller the budget, the fewer opportunities the country has.
The second phrase is «everything works well for us.» Maybe. But attackers evolve as quickly as technology. So think about when was the last time you did a security review? When did you look deeply at processes, tools, and trends? When was the last time you checked the internal perimeter?
To make these words not sound abstract, I will give some figures from industry reports for 2025–2026. According to the IBM Cost of a Data Breach 2025 report, the global average cost of a data breach is about $4.44 million, and in the US — a record $10.22 million. The average time to detect and contain an incident is 241 days, that is, almost eight months while the attacker is already inside. A vulnerability that is fixed in production costs about 100 times more than the same vulnerability that was built and fixed at the architecture stage. This is the famous «1-10-100 rule» (IBM Systems Sciences Institute). That is why it is worth starting to protect yourself on time.
What to include in the architecture at the start
For the best understanding, you need to delve into the project. Understand why it is important, what its value is for the business. Without this, any security advice will be general and useless.
Then the specifics begin. Do you know what architecture you have: physical server or cloud (AWS, Azure, GCP)? What will be the operating systems? The next step will be to find information about the vulnerabilities of your setup and options for their elimination. Next, you need to plan the coverage with security controls and settings. I advise you to start from CIS Benchmarks. At SharksCode, we take them as a base point and adapt them to the specific setup of the project. There are recommendations for configuring different systems for different needs.
Then you need an architecture and network map. Access profiles, RBAC, and MFA are already formed in accordance with it. Access needs to be regularly reviewed for relevance, issued to new employees, and revoked in a timely manner when a person leaves or changes role. The same at the network level. Determine what is allowed and what is prohibited, and record these rules in the documentation. Immediately establish this as an ongoing process.
If a business plans to obtain certifications (ISO 270xx, PCI DSS, SOC 2, or others), it is worth studying or reviewing what controls should be in place according to the certification.
The next step is to do a BIA (Business Impact Analysis) to understand what is most critical in your product, system, or project. Next, you should calculate how much it will cost to have what you are working on unavailable. After the analysis, move on to threat modeling (before writing any code) to understand possible attack vectors and vulnerabilities.
Don’t forget to build Change Management into your processes. Every change should be documented, have an owner, reviewer, and approver. Evidence of the changes made should be included.
Risk minimization plan
Usually, people advise «develop a risk mitigation plan.» The advice is good, but without specifics, it’s completely useless. That’s why I’m adding specifics.
People
Analyze your available resources. Do you have enough people working on information security — SOC, AppSec, DevSecOps, GRC? Do you need all of them at once? It’s up to you to decide depending on the project. The main thing is to understand who will be responsible for security before you start.
Tools
Next is the question of tools. If you don’t have them yet, you should decide on a strategy in advance: to go towards paid solutions or open source. Paid ones are usually easier. They are easier to integrate and have more functions. With open source, the story is different. It is actually very difficult to cover all the needs of a project with only open source tools. It takes a lot of time to configure them and connect them with the rest of the systems. At SharksCode, we combine both approaches depending on the needs of a specific product.
Resilience and recovery
Now imagine that the site has crashed due to an attack. Do you have a plan B? BCP, DRP, backups, mirroring work here — everything that allows you to quickly recover or at least minimize losses, don’t forget to check your backups to see if you can really recover from them and how long it takes, because every minute can cost a lot for the company. Firewall or WAF are responsible for protection at the traffic level. It is worth being prepared for such scenarios in advance.
Logging and constant monitoring
I will highlight monitoring separately, because it is your first line of defense. It determines whether you will see a problem in advance, or whether you will learn about it after the fact, or even from the users themselves.
You need to include in your logs your deployments, commit or access confirmations, any changes, failed account logins, and privileged actions. Regarding constant monitoring. Here you need to monitor vulnerabilities and fix them, monitor perimeters and incidents, and respond to incidents.
Security in the development pipeline
According to the recommendations of NIST SP 800-218 (Secure Software Development Framework), it can be divided into the following stages:
1. Preparation
- Defining roles and responsibilities.
- SSDLC documentation and policies.
- Training of the technical team (Dev, DevOps, QA, Architects…)
- Inventory of tools
- Requirements for software vendors
2. Product protection
- Source code protection.
- Control access to repositories.
- CI/CD protection.
- Protection of assembly artifacts.
- Secrets management.
3. Developing a secure product
-
Product safety requirements are established at the planning stage.
-
Threat modeling.
-
Architecture security check.
-
Secure code writing.
-
Expert verification.
-
Code security check.
-
SAST, SCA, Secret scanning, DAST.
-
Pre-release security testing.
4. Responding to vulnerabilities
- Constant monitoring of vulnerabilities.
- Prioritization and elimination.
- Root cause analysis.
- Re-check after corrections.
- Coordination of vulnerability disclosure.
I would add two comments here. The first is to get tools that you will actually work with: SAST, DAST, SCA, VM and pentest. The second is to adopt a shift-left security approach, that is, move security checks as close to the beginning of development as possible. The earlier you detect a problem, the cheaper it will cost you. According to IBM, fixing it at the testing stage costs about 15 times more than at the design stage, and in production — up to 100 times more.
Basic solutions that are expensive to change later
There is a category of architectural solutions that are cheap at the start, but very expensive after launch. These include authentication, authorization, segmentation, etc. Let’s get down to business.
For example, your cloud is currently accessible without a VPN and you decide to fix it. Will there be an impact on your business? You may have to pay for a VPN, there will be
an extra step to get to the cloud, and it will require the resources of the person setting it up. But overall it’s a normal workflow if you do it at the start.
And now the other side. Your product is already working and making money. At some point, a critical vulnerability appears that can only be fixed by stopping the service. Stopping a working service always leads to direct financial losses. Here, the business has to decide: lose profit or take the risk.
Or another example. You were not using encryption for certain data, and now, due to regulations or certification, it is necessary to implement it. Such manipulations involve major changes in the code and infrastructure, which will take up a lot of resources. Both situations would not have arisen if the solutions had been laid out at the beginning.
Principles that work in practice
Over the years of work, I have been convinced that these three principles really give results. These principles are part of the foundation of modern information security. Also, many international standards were based on these principles. Why are we talking about them now? It’s just that these are principles that determine how processes, systems, software and infrastructure should be designed at the architectural level.
Secure by default is the principle that a system should be configured as securely as possible out of the box. In practice, this means smart defaults. It’s worth setting this up right at the start, because then security scales naturally with the product.
OWASP recommends enabling TLS, security headers, private networks, secure cryptographic settings, and deny by default by default. I, in turn, can also add MFA, password policy, Audit logs. A little about the pros and cons that may be.
- Reduces configuration errors. (Most data leaks are caused by incorrect settings, not by errors in the code.)
- Provides a good starting level of security. (New environments immediately meet basic security requirements.)
- Accelerates secure deployment. (All teams use the same base configurations.)
- Less flexibility. (Secure settings may not be appropriate for certain business scenarios and require additional exceptions.)
- Higher initial threshold. (Developers may perceive strict policies as a barrier, especially in development environments.)
- Use hardened baseline configurations for servers, containers, and cloud services;
- Enable encryption, logging, MFA, and secure network settings by default;
- Automate configuration verification through Infrastructure as Code and CI/CD policies;
- Regularly update base configurations in accordance with new NIST, OWASP recommendations and standards requirements.
Least privilege is a principle according to which each user, service, process or system receives only those access rights that are necessary to perform a specific task, and no more. This principle is called one of the most effective ways to reduce the attack surface. «I like the way it works, people run around, hustle and bustle.» An example of what can happen if you neglect this principle: a new person came to you and you gave him maximum access so as not to waste time later. And the person turned out to be from a competitor and copied the code, databases, learned about your new features. If you had given the minimum necessary rights, this situation could have been avoided. Pros and cons!
- Reduces the attack surface. (If an account is compromised, an attacker does not gain full control over the system.)
- Reduces the risk of accidental errors. (Most incidents occur not because of hackers, but because of human errors.)
- Facilitates auditing
- Improves compliance. (Virtually all major standards directly or indirectly require Least Privilege.)
- High administrative complexity. (Supporting such an environment requires a mature access control process.)
- Can slow down teams.
- Requires constant review. (If permissions are not reviewed regularly, Privilege Creep occurs — the gradual accumulation of unnecessary permissions.)
- Use RBAC or ABAC;
- Implement Just-in-Time Access for administrative operations;
- Separate regular and privileged accounts;
- Conduct regular (e.g., quarterly) audits of access rights;
- Automatically revoke unused privileges.
Defense in depth — OWASP describes this principle as a combination of network isolation, authentication, authorization, input validation, encryption, monitoring, and other mechanisms so that the failure of one layer does not compromise the entire system.
Typical levels of protection include physical security, network segmentation, Firewall/WAF, IAM, MFA, encryption, Secure Coding, auditing, logging, SIEM, EDR, backup.
In my opinion, a strategy that is worth investing time and resources in and consciously building into the project architecture. Its essence is layering. You build several independent layers of controls (at the network, application, data, and identification levels). Any individual line will be breached sooner or later. You need to make sure that behind it is the next one that will stop or at least slow down the attacker and give you time to react. The last pros and cons.
- No single point of failure. (Compromising one control does not mean compromising the entire system.)
- Increases resistance to modern attacks. (Attacks usually consist of several stages. Each additional level increases the complexity of the attack and the chances of its detection.)
- Improves detection capabilities Cons:
- High cost.
- Increasing complexity
- False sense of security. (A large number of tools does not guarantee effective protection if they are not properly configured or monitored).
- Combine network segmentation, MFA, encryption, Secure Coding, SAST/DAST, WAF, SIEM, and EDR;
- Regularly test the effectiveness of each layer of protection through penetration testing and tabletop exercises;
- Avoid duplication of controls without added benefit.
Technical security debt
It accumulates fastest where there are many dependencies. For example, in working with product teams. Of course, new features for business are a higher priority. But it is important to find a common language and in each sprint take a certain percentage of tasks to close vulnerabilities. At SharksCode, this is built into the teams’ workflow. Otherwise, the debt grows silently, and you have to pay it off during an incident.
How to organize a security review before launch
If we look at standards such as PCI DSS, SOC 2, NIST, they all tell us that we need to implement a Shift Left approach. It is not without reason that implementing security at the beginning greatly helps your product to protect itself and scale in the future. Each of the standards describes the security review process in its own way, but I will try to show what the recommendations have in common and add my vision of this process.
Recommendations:
- Architecture model verification.
- Segmentation.
- Network settings.
- Cryptography.
- Secrets Management.
- Definition of assets.
- Attack scenarios.
- Risk assessment.
- Approval or adjustment of protection measures.
- Compliance with secure code writing standards.
- Authentication and authorization logic.
- Error handling.
- Input validation.
- Using cryptography.
- Infrastructure as Code verification.
- Configurations, for example, Kubernetes.
- Terraform verification.
- IAM verification.
- Network policies and settings.
My vision of the process:
If described at the level of principles, the review begins with an audit of processes and infrastructure settings. This is followed by scanning and pentests, checking for established vulnerabilities. At the time of release, there should be no unclosed critical and high ones. And finally, confirmation that all security and access control configurations are configured correctly.
This is not the work of one department. The Information Security team is most involved, but Dev, DevOps, and Product are also working closely. At SharksCode, we have built the process this way, because without their context, the review will be incomplete.
It’s worth mentioning the balance of automation and manual analysis (SAST, DAST, SCA, pentest, code review). What and when to use depends on the product, but they work best in tandem. Automation provides scale and speed, and manual analysis provides depth and context that the tool simply doesn’t see.
And it is telling that the «holes» most often found before a release are far from exotic. They are usually stored secrets, tokens or credentials that have been forgotten to be removed from the code or system files, default users, open ports. It is precisely because of their mundaneness that they so easily make it to production.
Process and people
How do you build security into the development cycle without becoming a «braking department»? I’ll be honest, some processes will slow down a bit. That’s how it should be. You and I need to not run, but consciously move in the right direction.
First, agree on the process with Dev, QA, PM, DevOps, and other teams. Second, give it time to run so everyone can see how it works in practice. Third, collect feedback and improve the process. After a few iterations, you will have exactly the process that suits your team. This is how the approach was formed at SharksCode.
The role of the Head of Platform and Application Security and the security team is close cooperation with the teams, not control from above. Together we determine the scope of work and everything that will be used. Then I help to formulate tasks from a security perspective: what to put into the architecture. When the architecture has been raised, configured according to recommendations, services and everything necessary have been raised, the integration of security systems begins. And only after that, actually, the security check.
Launch readiness criteria
The launch readiness criteria consist of several sequential checks. First, we analyze architectural changes and their impact on security, and then we look at the results of automated checks — SAST, DAST, Software Composition Analysis, Infrastructure-as-Code Scanning, and Secret Scanning. Next, we assess critical and high vulnerabilities and their remediation status, and check infrastructure settings, security configurations, and access controls. And based on all this, we confirm release readiness or determine what corrective actions are needed before launch.
Instead of a conclusion
A best practice for a modern organization is to build a Secure SDLC that meets the recommendations of standards. This approach simultaneously increases the level of development security, simplifies auditing, and reduces the risk of vulnerabilities before the code enters production.
A few thoughts from my experience: to build effective and well-thought-out information security on a project or in a company, you need to start at the very beginning. In today’s world, it’s not enough to know tools, techniques, and strategies. You also need to keep up with news, trends, and developments in related fields.
You need to understand the business, and to do this, be as involved as possible in most processes. What brings profit? What days and hours are the busiest? What are the integrations and contractors? Any information is useful for analysis, and on its basis you can understand the weaknesses of the system and build a working protection strategy. And separately
— communication within the company: an information security culture must be established for everyone, regardless of level and position. Don’t forget about the internal perimeter.
I also highly recommend that you periodically review and improve your processes. You need to change along with technologies and approaches. Be interested in different standards and approaches, try to systematically implement something new, but not in production, test it internally first.
Let me guess, you read this text and think: «I was hoping they would tell me step by step how to make security 100%.» First, there is no such thing as 100 percent. We should try to get closer to this value, but unfortunately, we cannot guarantee it. Second, to advise something truly effective, you need a complete understanding of the product, processes, and business. What works on our project may not work on yours.
I shared my experience and observations. Even AI can generate a step-by-step guide based on common practices, but without your context, there’s no guarantee that it will work for you. So the best option is to try and implement step by step what works for your business.
Read the country’s main IT news in our TelegramOn the topic
Read the country’s main IT news in our Telegram
How to pass GLI-19 without rewriting the architecture and simplify scaling: SharksCode caseOn the topic
How to pass GLI-19 without rewriting the architecture and simplify scaling: SharksCode case
IT company SharksCode: 2025 as a year of investment in technology and human capitalOn the topic
IT company SharksCode: 2025 as a year of investment in technology and human capital
«Code generated by AI does not enter the project in its pure form.» CTO SharksCode on Vibe Coding, AI assistance, and IT development prospectsOn the topic
«Code generated by AI does not enter the project in its pure form.» CTO SharksCode on Vibe Coding, AI assistance, and IT development prospects
