Настройка SAST (Static Application Security Testing) для сайта

Вы потратили две недели на отладку инцидента в продакшене — SQL-инъекция, которую не поймал динамический сканер. Знакомая ситуация. Мы внедряем SAST (Static Application Security Testing) прямо в CI/CD: анализ исходного кода без выполнения. SQL injection, XSS, hardcoded secrets, небезопасные функции — находим до мержа. На одном проекте с 10 разработчиками на TypeScript и Python мы внедрили Semgrep и CodeQL за 3 дня. Результат — 12 критических уязвимостей заблокированы на этапе PR, экономия времени на ревью — 40%. Одна из найденных уязвимостей — SQL-инъекция через шаблонные строки, которую не ловили статические анализаторы до внедрения кастомных правил. После настройки Semgrep с правилом на конкатенацию SQL, такие ошибки блокируются автоматически. Свяжитесь с нами для оценки вашего проекта.

Какие уязвимости находит SAST?

SAST покрывает весь OWASP Top Ten: SQL-инъекции, XSS, insecure deserialization, broken authentication. Например, Semgrep ловит прямую конкатенацию SQL в строках, а CodeQL отслеживает потоки данных для SSRF и RCE. Gitleaks находит API-ключи, токены и пароли, даже если они вмержины в git-историю. В одном проекте нашли AWS-ключ, который был закоммичен 3 года назад.

Инструменты SAST

Semgrep — быстрый, правила для 30+ языков, можно кастомные. Пример базового сканирования и кастомного правила для поиска прямой конкатенации SQL:

# Установка
pip install semgrep

# Сканирование с набором правил для безопасности
semgrep scan --config=p/security-audit \
             --config=p/owasp-top-ten \
             --config=p/typescript \
             --json > semgrep-results.json

# Кастомное правило: поиск прямой конкатенации SQL
cat > rules/sql-injection.yml << 'EOF'
rules:
  - id: raw-sql-concatenation
    patterns:
      - pattern: |
          "SELECT ... " + $VAR
      - pattern: |
          `SELECT ... ${$VAR}`
    message: "Potential SQL injection: use parameterized queries"
    severity: ERROR
    languages: [typescript, javascript]
EOF

semgrep scan --config=rules/sql-injection.yml src/

GitHub Advanced Security (CodeQL) — анализ потоков данных для сложных уязвимостей:

# .github/workflows/codeql.yml
name: CodeQL

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 0 * * 1'  # Еженедельно

jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
      actions: read

    strategy:
      matrix:
        language: [javascript-typescript]

    steps:
      - uses: actions/checkout@v4

      - name: Initialize CodeQL
        uses: github/codeql-action/init@v3
        with:
          languages: ${{ matrix.language }}
          queries: security-and-quality

      - name: Autobuild
        uses: github/codeql-action/autobuild@v3

      - name: Analyze
        uses: github/codeql-action/analyze@v3
        with:
          category: "/language:${{ matrix.language }}"

Поиск секретов

# Gitleaks: поиск секретов в коде и истории git
docker run --rm -v $(pwd):/path \
  zricethezav/gitleaks:latest detect \
  --source /path \
  --report-format json \
  --report-path /path/gitleaks-report.json

# truffleHog: анализ git истории
trufflehog git file://. --json > secrets-report.json

# GitHub Actions: pre-commit hook на секреты
- name: Check for secrets
  uses: gitleaks/gitleaks-action@v2
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}

ESLint Security плагины

npm install --save-dev eslint-plugin-security eslint-plugin-no-unsanitized @microsoft/eslint-plugin-sdl
cat > .eslintrc.json << 'EOF'
{
  "plugins": ["security", "no-unsanitized", "@microsoft/sdl"],
  "extends": [
    "plugin:security/recommended",
    "plugin:@microsoft/sdl/required"
  ],
  "rules": {
    "security/detect-object-injection": "error",
    "security/detect-non-literal-regexp": "warn",
    "security/detect-possible-timing-attacks": "error",
    "no-unsanitized/method": "error",
    "no-unsanitized/property": "error"
  }
}
EOF

Интеграция в CI/CD

Объединяем Semgrep и Gitleaks в один пайплайн (пример на GitHub Actions):

# .github/workflows/sast.yml
name: SAST

on: [push, pull_request]

jobs:
  combined:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/owasp-top-ten
            p/typescript
          auditOn: push
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

      - name: Secrets scan (Gitleaks)
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Сравнение инструментов SAST

Этапы внедрения SAST

Как интерпретировать результаты SAST?

Каждое предупреждение содержит описание уязвимости, строку кода и стек вызовов. HIGH и CRITICAL блокируют PR — их нужно исправить немедленно. WARNING и INFO попадают в backlog и назначаются на владельца кода. Мы рекомендуем проводить еженедельный triage новых находок. Это снижает количество игнорируемых уязвимостей и поддерживает чистоту кодовой базы.

Как настроить SAST в CI/CD за 1–2 дня?

Мы подключаем выбранные инструменты к вашему репозиторию: создаём workflow файл, настраиваем правила под стек (React, Node, Python — подтягиваем готовые наборы). Затем адаптируем пороги блокировки: HIGH и CRITICAL — фейл билда, все остальное — в backlog. Команда получает отчёт в виде Security Tab на GitHub или дашборда Semgrep.

Почему Semgrep лучше самописных скриптов?

Самописные регулярки падают на обфусцированном коде и не понимают контекст. Semgrep анализирует AST — различает eval(user_input) и eval(sanitized). В наших проектах это снижает число false positive на 40% по сравнению с grep-подходами. Плюс кастомные правила пишутся за 15 минут и применяются к сотням файлов.

Что входит в настройку SAST

• Выбор и установка одного или нескольких инструментов (Semgrep/CodeQL/Gitleaks)
• Адаптация правил под ваш стек технологий
• Интеграция в CI/CD (GitHub Actions, GitLab CI, Jenkins)
• Документация по интерпретации результатов
• Обучение команды (1 час воркшоп)
• Поддержка 2 недели после внедрения

С нашим опытом 5+ лет и 50+ проектов настройка SAST выполняется без сбоев. Гарантируем, что критические уязвимости блокируются до мержа. Закажите настройку SAST сегодня — оценим ваш проект за один день.

Правило SAST: не блокируем PR при каждом предупреждении — только при HIGH и CRITICAL. Остальные — в backlog security debt.

Безопасность веб-приложений: HTTPS, CSP, XSS, CSRF, WAF, защита от DDoS

Взлом сайта редко выглядит как в кино. Чаще это: бот нашёл endpoint /admin/export без авторизации, скачал базу клиентов, закрыл соединение. Или: через устаревший плагин WordPress залил веб-шелл, теперь сервер рассылает спам. Или тише: XSS в поле комментария позволяет красть session cookies администраторов, и никто не замечает месяцами. Мы такие случаи разбирали десятками — каждый раз уязвимость можно было закрыть на этапе разработки или аудита.

Безопасность веб-приложений — не одна настройка. Это слои защиты, каждый из которых закрывает отдельный класс атак. Закажите аудит — оценим проект и дадим план работ под ключ за 2–4 недели.

HTTPS и правильная конфигурация TLS

HTTPS — минимальный обязательный уровень. Но «есть SSL-сертификат» и «правильно настроен TLS» — разные вещи.

В конфигурации Nginx/Apache проверяем:

• Протоколы: только TLS 1.2 и TLS 1.3, SSLv3 и TLS 1.0/1.1 — отключены
• Cipher suites: предпочитать ECDHE (Forward Secrecy), убрать NULL, RC4, DES, 3DES
• HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains; preload) — браузер больше не делает незащищённых запросов
• OCSP Stapling — ускоряет проверку отзыва сертификата
• Redirect 301 с HTTP на HTTPS — и в конфиге сервера, и в коде (двойной редирект = потеря SEO-веса)

Проверка: SSL Labs (ssllabs.com/ssltest) должен показывать A или A+. Если B — конфигурация слабая.

Let's Encrypt + Certbot для продакшена — стандарт. Автоматическое обновление через certbot renew в cron. Wildcard-сертификат для поддоменов через DNS-01 challenge.

Content Security Policy: самая мощная и самая сложная защита

CSP — HTTP-заголовок, который говорит браузеру, откуда разрешено загружать ресурсы. Правильно настроенный CSP полностью блокирует большинство XSS-атак, даже если уязвимость есть в коде.

Проблема: сломать сайт неправильным CSP проще простого. default-src 'none' — и перестают работать шрифты, картинки, JS. Поэтому начинаем с Content-Security-Policy-Report-Only — CSP логирует нарушения, но ничего не блокирует. Смотрим репорты 2–4 недели, дорабатываем политику, потом переключаем на боевой режим.

Пример реальной политики для сайта с Google Analytics, Google Fonts и Stripe:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  report-uri /csp-report;

nonce — случайная строка, генерируется на сервере для каждого запроса. Inline-скрипты с правильным nonce разрешены, без nonce — заблокированы. Это ломает XSS через <script>alert(1)</script> полностью.

'unsafe-inline' в style-src — компромисс для inline-стилей. Лучше убрать, перенеся все стили в CSS-файлы, но это требует рефакторинга.

Почему XSS остаётся самой частой уязвимостью?

XSS (Cross-Site Scripting) — инъекция JS-кода через пользовательский ввод. По статистике OWASP, XSS входит в топ-3 уязвимостей веб-приложений. Три типа:

Защита: никогда не вставлять пользовательский ввод в HTML без эскейпинга. В PHP — htmlspecialchars() с ENT_QUOTES. В Blade-шаблонах Laravel — {{ $var }} безопасен, {!! $var !!} — опасен. В React — {variable} безопасен, dangerouslySetInnerHTML — опасен. Для Rich Text — htmlpurifier на PHP или DOMPurify в браузере.

CSRF: защита форм и API

CSRF (Cross-Site Request Forgery) — злоумышленник заставляет браузер жертвы отправить запрос от её имени. Пример: пользователь авторизован в банке, открывает вредоносную страницу, она делает fetch('https://bank.ru/transfer?to=evil&amount=50000') — если банк не защищён, деньги уходят.

CSRF-токены — стандартная защита для форм: сервер генерирует случайный токен, хранит в сессии, вставляет в форму как hidden field. При POST-запросе токен сверяется. Злоумышленник не знает токен. Laravel делает это автоматически через @csrf.

SameSite cookies — современная защита: SameSite=Strict или SameSite=Lax запрещает браузеру отправлять cookie в cross-site запросах. Работает во всех современных браузерах.

API без сессий (JWT, Bearer tokens) — CSRF неактуален, если токен не хранится в cookie (а в Authorization header или localStorage). Но localStorage уязвим к XSS — поэтому для чувствительных данных предпочтительны HttpOnly cookies с SameSite.

WAF и защита от DDoS

WAF (Web Application Firewall) — фильтрует HTTP-трафик на предмет атак: SQL injection, XSS, path traversal, известные exploit patterns. Варианты:

• Cloudflare WAF — облачный, правила OWASP Top 10 из коробки, кастомные правила через выражения. Managed Rules автоматически блокируют новые угрозы.
• ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Гибко, но требует настройки и мониторинга ложных срабатываний.
• AWS WAF — для инфраструктуры на AWS, интегрируется с CloudFront и ALB.

DDoS-защита. Cloudflare на уровне L3/L4/L7 — де-факто стандарт для большинства сайтов. Автоматическое смягчение volumetric атак, Under Attack Mode при активной атаке. Для критичной инфраструктуры — Cloudflare Magic Transit или специализированные решения (Qrator, StormWall для российского рынка).

Rate Limiting на уровне приложения — дополнительный слой. Laravel ThrottleRequests middleware: 60 запросов в минуту на IP для общих endpoint, 5 — для /login и /password/reset. Redis как хранилище счётчиков — обязательно для горизонтально масштабируемых систем (иначе лимиты не синхронизируются между серверами).

Другие обязательные меры

Заголовки безопасности. Помимо CSP: X-Frame-Options: DENY (защита от clickjacking), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (ограничение доступа к API браузера: камера, микрофон, геолокация).

SQL injection. Prepared statements везде. Никаких конкатенаций пользовательского ввода в SQL-строки. ORM (Eloquent, Doctrine) защищает по умолчанию. $wpdb->prepare() в WordPress — обязательно.

Обновления зависимостей. composer audit и npm audit — в CI/CD пайплайн. Dependabot или Renovate для автоматических PR с обновлениями. Критичные CVE — патчить в течение 24 часов.

Секреты и конфигурация. .env — никогда в Git. Секреты в production — через переменные окружения CI/CD (GitHub Secrets, GitLab CI Variables) или HashiCorp Vault. Проверка на утечки: git-secrets, truffleHog в pre-commit hooks.

Как мы работаем

1. Аудит — сканирование кода, конфигураций, зависимостей, ручная проверка бизнес-логики.
2. Проектирование — план устранения уязвимостей, подбор стека (CSP, WAF, rate limiting).
3. Реализация — настройка TLS, CSP, заголовков, внедрение Rate Limiting, WAF.
4. Тестирование — повторный пентест, нагрузочное тестирование, проверка ложных срабатываний.
5. Деплой и мониторинг — включение боевого CSP, настройка алертов, обучение команды.

Что входит в работу

• Отчёт с найденными уязвимостями и рекомендациями (PDF + code snippets)
• Готовая конфигурация TLS (Nginx/Apache)
• Политика CSP с режимом Report-Only и боевой версией
• Настройка WAF и Rate Limiting
• План обновлений зависимостей
• Доступы к инструментам мониторинга (Sentry, Datadog)
• 30 дней постаудит-поддержки (консультации, правки)

Сроки и стоимость

Бюджет рассчитывается индивидуально — напишите нам, чтобы оценить проект.