Security: Vulnerabilities Are Born in Architecture

Roman Lebed introduces himself as a security architect at Tinkoff: two years in the company, arrived as the lead of the AppSec team, and now owns a line of three products — service security, DevSecOps technologies, and the protection of the external infrastructure and the perimeter. The team is around fifteen people, split into a platform part that builds security into the internal development platform — an episode about that platform with Dima Gaevsky had come out the day before — and an engineering part building tooling that assesses how well products are protected. The principle is simple: do not start processes that cannot be scaled to every application; manual analysis and security architects are reserved for the most critical, platform segments. The focus, Roman says, has moved from protecting every service in breadth towards assembling a secure architecture out of ready-made blocks — an approach described in Google's book on building secure systems, which, Alexander notes, Code of Architecture has not covered yet.

Alexander recalls an early episode on Team Topologies and the questions left under that video: what is a security team today. Roman sorts it by role: when they build a security product with clear consumers, that is a product team of its own; for the development platform they are a platform team and an inseparable part of it; in architecture reviews they are an enabling team that hands expertise to software architects and deliberately refuses to take the function over. He explains the priority of the three products this way: the infrastructure is a potential single point of compromise for most services, while the perimeter, judging by public reports on attacks, remains — after the human factor and social engineering — one of the most problematic zones in the world. Hence a double goal: raise the security of the perimeter and remove the perimeter as such, holding every network asset to the requirements of something exposed outwards. Alexander adds that at reviews questions of security, reliability, and resources are usually settled by dropping a custom solution in favour of platform blocks.

They arrived at the current model recently: expertise is increasingly handed to the teams — developers, SRE, QA, and now product managers too. The trigger was the realisation that many vulnerabilities are born not in implementation but in design. An architect, in their understanding, is not someone assembling ready solutions from standard templates but someone who can pick the best solution even when it does not yet exist on the market and design a system from scratch. A couple of months ago they started an experiment: security architects join teams from the start of the design, show how they identify threats, walk through the top ten design anti-patterns, and hand over ready recipes — how to arrange an exchange of cryptographic keys, how to build administrator access and emergency access mechanisms. All of it is collected in an internal Shift Left Security Book open to any employee; new developers are assigned a secure development course at hiring — how to triage static analyser findings themselves, how to use the publication service. A separate training team is considering an interactive platform that picks tasks by the employee's stack: a Python developer would find and fix a vulnerability and write security tests, all as a quest with points.

Alexander asks how the team copes with the load in such a model. The answer: regular retrospectives and feedback to the teams, their own system for scoring projects, and the 80/20 principle — a full analysis cannot be estimated up front, so a project gets an allotted time and they do the maximum within it. Work becomes more predictable, and they meet the team several times a week — unlike conservative security teams that analyse a project for months and then bring back a solution that may not satisfy the functional requirements; Alexander compares it to a progressive JPEG that appears gradually. The second answer is to move expertise into code: few people work with teams directly. The R&D team is building baseline threat modelling without a human — rather than forcing teams to describe architecture diagrams formally, they use machine learning over documentation and even meeting recordings to show the architect a baseline set of threats. Alexander says a pilot would make a conference talk.

Roman wears several hats and steps in where the team cannot manage without him. As an architect he takes part in the design, requirements, and acceptance of the most critical systems, and sometimes reads the code himself; as the head of a small R&D team he chooses the most promising research directions and mentors newcomers; as a technical product manager he owns the product side — the department spent about a year moving from service, functional teams to products. He describes the key metric for automated processes as the number of vulnerabilities multiplied by the mean time to fix and by an average criticality coefficient, adjusted for the number of developers: the point is to cut the number of defects and the time a developer spends fixing them. Alexander notes that only strong engineers carry such a role — people who build not systems but products for particular consumers — and the participants note that candidates equally strong in engineering and in product are very rare.

The information security profession inside the company is only just starting: Roman so far drives it from the inside alone, demand is modest, and splitting it into infrastructure security, AppSec, monitoring, and forensics is blocked by size — each would hold about ten people. Alexander retells his own episode on Staff+ engineers: instead of an architect job title sitting above development, the company chose roles — domain tech lead, architect, and a firefighter thrown from project to project. A year ago they agreed to fold security into the level-transition requirements of other professions, differentiated by track: secure coding, patterns and anti-patterns for developers; secret storage, secure delivery, and administration for infrastructure engineers. Training everyone is still impossible — people change, the company grows — so a project generating autofixes is being rolled out: on top of the static analyser, a model explains the cause of a vulnerability and offers a fix behind an apply-suggestion button in the IDE. There are many open positions, with a tech lead for perimeter protection and AppSec engineers as the priority.