От списка инструментов к technical output: как security engineer’у описывать hands-on опыт в CV и на интервью

Многие специалисты в кибербезопасности умеют делать нормальную hands-on работу: разбирать findings, настраивать SAST/SCA/DAST, проверять API, ковырять CI/CD, писать скрипты, закрывать cloud misconfigurations, помогать разработчикам исправлять уязвимости ит.д. Но при поиске работы такой опыт (а, точнее его подача, упаковка) часто описывается слишком слабо.

В резюме получается что-то вроде этого микса:

Работал с Burp Suite, SAST, SCA, SIEM, Kubernetes, AWS.
Занимался анализом уязвимостей.
Участвовал в DevSecOps-процессах.
Помогал разработчикам исправлять баги.

Формально все правда, да, не подкопаться. Но hiring manager или technical interviewer видит не результат, а набор общих слов (и зачастую ему не очень понятных). Отсюда тебя меньше замечают на job board, меньше конверсия апликейшинов поданных на позиции, и соответственно последующих собеседований, ну, и по итогу потенциальный проигрыш в цене оффера.

Проблема не в том, что инструменты не важны. Важны, очень даже (твой тимлид оценит). Но список инструментов сам по себе не показывает, какую задачу человек решал, в каком масштабе, насколько самостоятельно работал и что стало лучше после его действий.

В этой статье разберем, как hands-on специалисту в AppSec, DevSecOps, pentest, vulnerability management, cloud security или SOC описывать свой опыт так, чтобы было видно не только “я работал с тулзами”, а конкретный technical output.

Коротко: о чём статья

Разберём:

• почему “работал с Burp / SAST / Kubernetes” звучит слабее, чем кажется;

• какие 5 слоев опыта стоит показывать в CV и на интервью;

• как переводить обычные технические задачи в понятный (бизнес) результат;

• как переписывать слабые CV bullets;

• какие метрики использовать без выдуманного impact;

• как готовить личные STAR stories для technical interview;

• как говорить о своём опыте без воды, пафоса и самообмана.

---

Почему список инструментов не продаёт опыт

Одна из частых ошибок технических кандидатов — считать, что сам факт владения инструментом уже объясняет ценность опыта.

Например:

Burp Suite, Nmap, Nessus, GitLab CI, Docker, Kubernetes, AWS, Python.

Для технического человека это может выглядеть нормально: стек перечислен, ключевые слова есть. Но со стороны работодателя такой список отвечает только на один вопрос: с чем человек сталкивался.

Он не отвечает на более важные вопросы:

• что именно человек делал;

• в каком масштабе;

• какие проблемы решал;

• что стало лучше после его работы;

• можно ли ему доверить участок процесса без постоянного контроля;

• умеет ли он общаться с разработчиками, DevOps, product teams;

• понимает ли он риск, а не только output инструмента.

Работодатель редко ищет просто “человека, который запускал SAST”. Чаще ему нужен человек, который может:

• встроить SAST/SCA в pipeline;

• снизить false positives;

• сделать findings понятными для dev teams;

• настроить ownership;

• ускорить triage;

• повысить coverage;

• не сломать delivery;

• довести high-risk findings до validated fix.

Это уже не список инструментов. Это technical output. И соответственно, здесь нужна грамотная подача. И так, разберем это на мини примерах ниже.

Почему “занимался уязвимостями” звучит слабо

Фраза:

Занимался анализом уязвимостей.

может означать всё что угодно. Один человек просто экспортировал отчёт из сканера.
Другой — разбирал 100+ findings в месяц, отделял exploitable risk от мусора, назначал ownership, контролировал SLA и помогал командам закрывать critical/high backlog.

Оба могут написать “занимался уязвимостями”. Но уровень работы разный. То же самое с другими формулировками:

Главный фильтр простой:

Если bullet можно применить почти к любому человеку из отдела, он слабый.

Что на самом деле нужно показывать

Для hands-on security roles я бы раскладывал опыт на пять слоёв (даю по аннлийски):

1. Stack — с чем ты реально работал.

2. Scope — в каком масштабе.

3. Evidence — чем это подтверждается.

4. Impact — что стало лучше.

5. Autonomy — насколько самостоятельно ты мог довести задачу до результата.

И, так, давай разберем каждый слой.

1. Stack: не просто tools, а контекст применения

Stack — это не список ради списка.

Плохо:

SAST, SCA, DAST, Burp, Docker, Kubernetes, AWS.

Лучше:

Integrated SAST/SCA checks into GitLab CI pipelines, performed manual web/API testing with Burp Suite, reviewed Kubernetes workload configs for secrets, RBAC and network exposure.

Во втором варианте видно, как именно использовались инструменты.

Для AppSec это может быть:

• SAST/SCA/DAST;

• Burp Suite;

• OWASP ASVS / Top 10;

• API testing;

• secure code review;

• threat modeling;

• secure SDLC.

Для DevSecOps:

• GitLab CI / GitHub Actions / Jenkins;

• secrets detection;

• IaC scanning;

• policy-as-code;

• container scanning;

• dependency scanning;

• security gates.

Для vulnerability management:

• scanner output;

• asset inventory;

• SLA;

• KEV / EPSS;

• exposure;

• remediation tracking;

• dashboards.

Для cloud security:

• IAM;

• public exposure;

• CSPM;

• logging;

• encryption;

• Kubernetes;

• Terraform;

• least privilege.

Инструменты важны. Но они должны быть связаны с задачей.

2. Scope: без масштаба опыт выглядит меньше

Масштаб — один из самых недооценённых элементов в CV и интервью.

Сравните:

Настраивал SCA.

и:

Integrated SCA checks for 30+ repositories and mapped vulnerable dependencies to responsible product teams.

Во втором варианте понятнее уровень задачи.

Scope можно показывать через:

• количество repositories;

• количество сервисов;

• количество product teams;

• количество monthly findings;

• количество endpoints;

• количество cloud accounts;

• количество pipelines;

• количество incidents / alerts;

• external-facing assets;

• selected product line;

• organization-wide workflow.

Если точные цифры нельзя раскрывать, можно использовать аккуратные диапазоны:

• 20+ repositories;

• multiple product teams;

• 100+ monthly findings;

• several cloud accounts;

• selected product line;

• external-facing services;

• from manual weekly report to automated dashboard.

Это не раскрывает чувствительные детали, но даёт читателю контекст.

3. Evidence: чем подтверждается твой опыт

Security — область, где “поверьте мне” работает плохо.

Хорошо, когда у кандидата есть evidence:

• sanitized reports;

• GitHub snippets;

• pipeline examples;

• detection rules;

• dashboards;

• playbooks;

• checklists;

• diagrams;

• lab writeups;

• STAR stories;

• safe screenshots без чувствительных данных;

• примеры структуры отчётов;

• публичные заметки или статьи.

Для junior / middle это особенно важно. Если коммерческого опыта мало, можно показывать:

• lab;

• CTF / HTB writeups;

• parser для scanner reports;

• demo CI policy;

• чеклист по ASVS;

• пример vulnerability report;

• mini dashboard;

• automation script;

• notes по threat modeling.

Важно: не нужно выкладывать рабочие секреты, PoC, чужой код или чувствительные данные. Но безопасные артефакты сильно помогают показать, что человек умеет делать руками, а не просто перечисляет keywords.

4. Impact: что стало лучше

Impact — это не обязательно “сэкономил компании миллион долларов”.

В security часто достаточно честно показать техническое улучшение:

• повысил coverage;

• снизил false positives;

• ускорил triage;

• сделал ownership понятным;

• сократил manual reporting;

• улучшил visibility;

• помог закрыть high-risk findings;

• стандартизировал workflow;

• сделал проверку повторяемой;

• снизил recurring issues.

Пример:

Плохо:

Писал отчёты по безопасности.

Лучше:

Prepared actionable security reports with severity, evidence, remediation steps and retest status, helping development teams prioritize fixes.

Ещё лучше, если есть scope:

Prepared actionable security reports for web/API assessments, including evidence, remediation steps and retest status for high-risk findings before release.

Здесь видно не просто “писал отчёты”, а зачем они были нужны. Это уже хорошая, уверенная подача. Ты продаешь не просто рутину, а свой результат (то самое, по факту за что и платит работодатель нанимая тебя)

5. Autonomy: можешь ли ты закрывать задачу, а не просто выполнять поручение

Для middle / senior hands-on роли важно показать autonomy.

То есть способность:

• разобраться в проблеме;

• собрать facts;

• проверить assumptions;

• предложить fix;

• договориться с dev / team lead;

• провести retest;

• оставить после себя понятный workflow.

Фраза:

Мне поручали задачи по безопасности.

звучит слабее, чем:

I identified recurring scanner noise, tuned severity policy and suppression workflow, and helped product teams focus on exploitable findings.

Autonomy не означает “я был руководителем”.

Можно не быть менеджером, но иметь ownership за technical outcome.

---

Technical value map: как переводить обычную работу в ценность

Ниже простая карта перевода технических действий в engineering value.

Эта таблица полезна не только для CV. По ней можно готовить LinkedIn, self-intro, интервью и performance review. Можно сочетать о разному, прояви свою творческую силу и собери уникальный профиль с авторской подачей.

Формула хорошего CV bullet

Я бы рекомендрвал использовать такую формулу:

Action + Scope + Tool/Method + Evidence + Impact

Или по-русски:

Сделал X для Y, используя Z, в масштабе N, чтобы улучшить / снизить / ускорить / стандартизировать R.

Примеры. Дальше буду формулировать по английски.

Плохо:

Настраивал SAST.

Сильнее:

Integrated SAST into GitLab CI pipelines for 20+ repositories and tuned rules to improve signal quality for development teams.

Плохо:

Работал с Burp Suite.

Сильнее:

Performed manual web/API security testing with Burp Suite, validating auth, session management and business logic issues.

Плохо:

Занимался анализом уязвимостей.

Сильнее:

Triaged and prioritized vulnerability findings across internal services using severity, exploitability and asset exposure.

Плохо:

Помогал разработчикам исправлять баги.

Сильнее:

Worked with developers to validate fixes and reduce recurring security defects through retest and actionable remediation guidance.

---

Мини-кейс 1: SAST/SCA в CI/CD

Слабая подача:

Настраивал SAST и SCA в CI/CD.

Что непонятно:

• для скольких репозиториев;

• какой был pipeline;

• были ли rules;

• что делали с false positives;

• кто владел findings;

• что стало лучше.

Сильная подача:

Integrated SAST/SCA checks into GitLab CI for 30+ repositories, tuned severity thresholds and suppression workflow, and mapped findings to responsible product teams to improve remediation ownership.

Почему это лучше:

• есть action — integrated, tuned, mapped;

• есть scope — 30+ repositories;

• есть context — GitLab CI;

• есть engineering value — remediation ownership;

• видно, что человек думал не только про scanner, но и про процесс.

Мини-кейс 2: vulnerability management

Слабая подача:

Работал с vulnerability scanner и CVEs.

Сильная подача:

Triaged 100+ monthly vulnerability findings across internal and external-facing assets, prioritizing remediation by severity, exploitability, exposure and business criticality.

Почему это лучше:

• есть объём;

• есть тип assets;

• есть зрелая приоритизация;

• не только CVSS;

• видно понимание risk-based подхода.

Для vulnerability management не стоит ограничиваться только CVSS.

В реальной приоритизации часто учитывают:

• exploitability;

• exposure;

• business criticality;

• KEV;

• EPSS;

• asset context;

• compensating controls;

• наличие public exploit;

• internet-facing поверхность.

Фраза:

Prioritized internet-facing and KEV-listed vulnerabilities first.

звучит намного сильнее, чем:

Worked with CVEs.

Потому что первая формулировка показывает ход мышления.

Мини-кейс 3: pentest / API security

Слабая подача:

Проводил тестирование API.

Сильная подача:

Performed targeted API security testing before release, validating authorization bypass, token handling, IDOR-like paths, rate limits and error handling; documented PoC and retested fixes with developers.

Почему это лучше:

• понятно, что именно проверялось;

• есть безопасная PoC-дисциплина;

• есть retest;

• есть работа с разработчиками;

• результат связан с релизом.

Для pentest / offensive roles важно показывать не только “нашёл баг”, но и:

• evidence;

• exploitability;

• impact;

• remediation;

• retest;

• report quality;

• умение не ломать production;

• умение объяснить риск.

Мини-кейс 4: cloud security

Слабая подача:

Проверял AWS.

Сильная подача:

Reviewed cloud misconfigurations around IAM permissions, public storage exposure, logging and encryption coverage, then created repeatable checks to reduce recurring issues.

Почему это лучше:

• понятно, какие классы misconfigurations проверялись;

• видно, что была не разовая проверка, а repeatable checks;

• есть outcome — снижение recurring issues.

Для cloud security хорошо звучат:

• IAM least privilege;

• public exposure;

• logging coverage;

• encryption;

• Kubernetes workload configs;

• Terraform / IaC scanning;

• CSPM findings;

• misconfiguration MTTR.

---

ATS keywords: как не превратить CV в мусор

Да, keywords важны. ATS и recruiters часто сначала матчят vocabulary, а уже потом смотрят твой опыт, сертификаты, рекомендации, пет проекты и т.д. И, вот что здесь будет релевантно:

• SAST;

• SCA;

• DAST;

• Kubernetes;

• AWS;

• Terraform;

• Burp Suite;

• OWASP;

• threat modeling;

• incident response;

• vulnerability management;

• CI/CD security.

Но keyword stuffing быстро ломается на technical screen. Ибо на этом этапе ты показываешь не знание аббревиатур и названия тулов, а лаешь представление о том что ты использовал в работе, почему именно это, какие проблемы\задачи это закрывало, и что конкретно ты можешь сказать о своем (не всей команды) вкладе в результат.

Плохо:

SAST, SCA, DAST, DevSecOps, Kubernetes, Cloud Security, Threat Modeling, Incident Response.

Лучше будет так:

Правило простое:

Берём vocabulary вакансии и связываем его с реальными примерами.

Technical interview: что проверяют на самом деле

На technical interview проверяют не только знание инструмента.

Проверяют thinking process:

• как человек собирает facts;

• как строит гипотезы, на что опирается при решении задачи;

• как проверяет assumptions;

• как выбирает trade-offs;

• как объясняет risk (технический и бизнес);

• умеет ли признать неизвестное и брать ответственность;

• не пытается ли продавать fake expertise.

Даже если вопрос узкий, лучше отвечать структурно. Ниже чуть подробнее пробежимся по ключевым поинтам такого интервью.

Design / architecture

Формат ответа:

1. уточнить assumptions;

2. описать data flow;

3. определить trust boundaries;

4. предложить controls;

5. объяснить trade-offs.

Фраза:

I would first clarify data flow, trust boundaries and deployment model, then choose controls.

Troubleshooting

Формат ответа:

1. reproduce;

2. logs;

3. scope;

4. isolate;

5. fix;

6. validate.

Фраза:

I would check whether it is a scanner issue, pipeline config issue or actual dependency exposure.

Tooling

Не просто:

I used scanner X.

А:

The hard part was not enabling the scanner, but tuning severity, ownership workflow and false positives.

Security finding

Формат:

1. evidence;

2. exploitability;

3. impact;

4. remediation;

5. retest.

Фраза:

I would provide PoC, affected endpoint, risk, fix recommendation and validation criteria.

Unknown topic

Хороший ответ:

I have not run this exact setup in production, but I understand the underlying model and would test it this way.

Это лучше, чем уверенно фантазировать.

В security доверие часто важнее театра.

---

STAR stories для технаря

STAR часто воспринимают как HR-шаблон. Но для hands-on кандидата это нормальный способ структурировать technical stories (особенно на западном рынке).

Главное — не превращать STAR в менеджерскую речь.

S — Situation

Контекст:

• какая система;

• какая команда;

• какой риск;

• какое ограничение;

• почему задача была важна.

T — Task

Что было на тебе:

• внедрить проверку;

• разобрать backlog;

• провести testing;

• снизить noise;

• сделать dashboard;

• автоматизировать report;

• провести retest.

A — Action

Что ты сделал руками:

• tools;

• scripts;

• configs;

• tests;

• validation;

• communication with dev team.

R — Result

Что изменилось:

• быстрее triage;

• меньше false positives;

• понятнее ownership;

• выше coverage;

• меньше manual work;

• validated fixes;

• более безопасный release.

Пример STAR 1: DevSecOps / SCA

Situation: зависимости проверялись нерегулярно, findings приходили поздно и без ownership.

Task: встроить SCA в CI/CD для группы сервисов и сделать процесс triage пригодным для разработчиков.

Action: подключил scanner, настроил policy thresholds, suppression workflow, ownership mapping и weekly export.

Result: команда начала видеть vulnerable dependencies до релиза, manual reporting сократился, а backlog high/critical стал управляемым через SLA.

Пример STAR 2: API security

Situation: перед релизом API не было уверенности в auth/session controls.

Task: провести targeted testing и дать actionable findings.

Action: проверил authorization bypass, token handling, IDOR-like paths, rate limits и error handling; оформил PoC без разрушительных действий; после fixes сделал retest.

Result: критичные paths закрыли до релиза, команда получила checklist для похожих endpoints.

---

Self-intro на 45 секунд

Self-intro должен дать интервьюеру карту:

• кто ты;

• в чём специализация;

• какой stack в работе;

• какой scope;

• какие задачи хочешь решать дальше\что ищешь для себя.

Плохо (очень плохо):

Я ответственный, коммуникабельный, быстро обучаюсь и люблю кибербезопасность.

Лучше:

Я AppSec / DevSecOps engineer с hands-on опытом в SAST/SCA/DAST, CI/CD security и vulnerability triage. Работал с product teams, подключал scanners в pipeline, настраивал rules и помогал разработчикам доводить findings до fixes. Мне интересны роли, где нужно не просто запускать tooling, а сделать security checks usable для engineering: меньше шума, быстрее feedback, понятный ownership и нормальные отчёты.

Здесь есть все собрано в один эффективный флоу:

• роль;

• специализация;

• stack;

• практический контекст;

• value;

• направление развития.

Без лишнего пафоса. По делу. Коротко. Грамотный HR или Лид тебя поймет.

---

Типичные ошибки русскоязычных кандидатов

1. Слишком скромная подача

Плохо:

Ну я просто помогал с уязвимостями.

Лучше:

I triaged vulnerability findings, mapped ownership and helped reduce aging critical backlog.

Не нужно принижать свой вклад. Если ты реально делал руками — говори конкретно.

2. Слишком много технических деталей без контекста

Плохо:

10 минут рассказывать про flags, YAML и настройки scanner.

Лучше:

Сначала риск и задача. Потом детали, если interviewer попросит.

Принцип:

Summary first, depth on demand.

3. “Мы” вместо “я”

Если всё время говорить “мы”, непонятно, где твой вклад.

Нормальная формула:

• team achieved;

• I owned;

• I implemented;

• I automated;

• I validated;

• I supported remediation.

4. Боязнь конкретных цифр, метрик, показателей

Без масштаба всё звучит маленьким.

Можно использовать диапазоны:

• 20+ repos;

• multiple product teams;

• 100+ monthly findings;

• selected product line;

• external-facing services.

5. Негатив о прошлой работе

Плохо:

Там всё было плохо, разработчики ничего не понимали.

Лучше:

There was friction because scanner findings were noisy, so I focused on false positive reduction, severity policy and making reports actionable for developers.

Это взрослая позиция. Не говори плохо, говори аргументированно. Показывай что ты развиваешься, что из любой ситуации находишь выход. Растешь сам, там где боль\проблема — точка роста, а не депрессии! Прошлые провалы\непонимание дали импульс к развитию.

6. CV как список технологий

Плохо:

Burp, Nmap, Nessus, GitLab, Docker, Kubernetes, AWS, Python.

Лучше:

Performed web/API testing with Burp Suite, validated auth/session issues and supported remediation through retest.

---

Какие вопросы задавать hiring manager

Хорошие вопросы показывают твою зрелость, мотивированность. Не задать вопрос, сказать что все понятно или ты все уже знаешь о компании\работе — в 90% будет промахом. Например, очень хорошо будут звучать такие вопросы:

• Как сейчас устроен vulnerability triage и кто владеет remediation?

• Какие security checks уже встроены в CI/CD, а где ещё gaps?

• Что будет считаться успешным результатом через первые 90 дней?

• Сколько product teams / repos / services входит в scope роли?

• Как команда измеряет false positives, SLA и developer adoption?

• Какой баланс между manual review, automation и developer enablement?

• Какие security issues сейчас болят сильнее всего?

Такие вопросы показывают, что кандидат думает не только “какие тулзы дадут”, а “какую проблему нужно решить”. Это уже problem-solved подход, и он ценится, особенно на позициях senior.

Про деньги: как говорить без зажатости и агрессии

Разговор о compensation часто ломает сильных технических кандидатов. Одна крайность — назвать минимальную цифру из страха и зажать потенциал оффера. Другая — агрессивно торговаться без понимания scope роли. Обе крайности ведут в тупик.

Более здоровая формула:

Based on the role scope and my hands-on experience with AppSec/DevSecOps automation, I am targeting a range around X–Y. I am flexible depending on total compensation, remote setup, responsibilities and growth path.

Смысл простой:

Я понимаю свою ценность, готов обсуждать её в контексте роли. Я могу принять компромиссы или пойти на уступку понимания свой вклад и потенциал проекта.

Не “возьмите меня, пожалуйста”. И не “я звезда, платите максимум”. А спокойная профессиональная позиция. ЭТО ОЧЕНЬ ВАЖНО!

Финальный чеклист

Перед отправкой CV или интервью можно пройти короткую проверку:

• Я могу объяснить специализацию за 45 секунд без воды.

• В CV видно не только tools, но и scope.

• У меня есть минимум 5 STAR stories по реальным technical tasks.

• Я умею говорить “я сделал” там, где это мой вклад.

• Я не преувеличиваю опыт, но и не обесцениваю себя.

• Я показываю automation, triage, validation, documentation и collaboration with dev teams.

• Я могу объяснить, чем моя работа снижала risk, ускоряла feedback loop или улучшала coverage.

• У меня есть вопросы к работодателю.

• Я знаю свой salary range.

• Я не называю самую низкую цифру из страха.

Полезные источники для контекста

Если уже работал с application security, vulnerability management или DevSecOps, полезно держать под рукой:

• OWASP ASVS;

• OWASP Top 10;

• CISA Known Exploited Vulnerabilities Catalog;

• FIRST EPSS;

• NIST Secure Software Development Framework.

Это не “магические списки”, которые заменяют мышление. Но они помогают говорить с командами на более понятном языке: risk, exploitability, exposure, controls, verification, remediation priority.

---

Что по итогу

Можно оставаться hands-on специалистом. Можно писать скрипты, гонять scanners, проверять API, разбирать findings, чинить CI/CD, делать retest и помогать разработчикам. Не обязательно становиться менеджером, чтобы твой опыт выглядел сильнее. Но нужно уметь показывать technical output так, чтобы было видно не просто “ещё одного человека со списком тулзов”, а инженера, который:

• закрывает реальные security gaps;

• делает процессы повторяемыми;

• снижает шум;

• ускоряет feedback;

• помогает командам чинить важное;

• понимает risk, scope и impact.

Хорошая упаковка опыта — это не самопиар и не преувеличение. Это способ честно показать, что именно ты умеешь делать, в каком масштабе и какой результат после этого остаётся.

Если тема будет интересна, в следующей статье можно отдельно разобрать несколько обезличенных примеров CV bullets для AppSec / DevSecOps / Cloud Security ролей: что в них слабое, как их переписать и какие вопросы по ним могут задать на technical interview. И кому интересно, подписывайтесь на мой ТГ канал White2Hack, там я выкладываю много исследований, документов и полезных ништяков!