사이트 상태 및 보안 보고서은(는) 무엇을 하나요?

웹사이트의 일일(또는 주간/월간) 건강 및 보안 보고서를 바쁜 소유자를 위해 평이한 언어로 등급과 함께 생성하는 에이전트 스킬입니다. ElectroHire가 설계하고 모든 스택에 일반화한 방법론으로, 원래 회사의 프로젝트는 이 방법론의 일부가 아닙니다.

보고서는 매 호마다 증거와 함께 다섯 가지 질문에 답변합니다:

사람들이 사이트에 접속할 수 있었으며, 실제 트래픽은 어땠습니까?
검색 엔진과 AI 크롤러가 사이트를 찾고 인용할 수 있습니까 (SEO/AEO)?
코드가 안전합니까: 취약한 의존성, 코드 스캔 결과, 유출된 비밀?
경계가 유지되고 있습니까: TLS, 보안 헤더, 이메일 인증, 사이트 및 API의 DDoS 보호?
가장 영향력이 큰 3~5가지 조치는 무엇이며, 각각의 책임자는 누구입니까?

모든 호는 A부터 F까지 등급이 매겨지며, 종합 등급과 세 가지 하위 등급(트래픽 및 신뢰성, SEO/AEO, 보안 및 코드 건강)으로 제공됩니다. 모든 등급 하락은 한 줄로 원인을 명시합니다. 숫자는 절대 가상이 아닙니다: 실행할 수 없는 소스는 그 이유와 함께 "사용 불가"로 보고됩니다.

규칙 0: 스택 인테이크 없이 이 스킬을 실행하지 마십시오

Cloudflare, GitHub 또는 다른 공급업체를 가정하지 마십시오. 첫 번째 보고서 전에 references/stack-intake.md에서 사용자와 함께 스택 인테이크를 완료하고 보고서 설정으로 저장하십시오 (템플릿: templates/config.example.json; templates/config.example.yaml은 사람이 읽을 수 있는 미러이며, JSON 파일은 도구가 읽는 설정 기록입니다). 저장된 파일 이름은 config.local.json(git-ignore 처리됨)이며, 자격 증명은 위치로만 기록합니다("볼트 항목 X"), 절대 값을 기록하지 마십시오. 인테이크는 다음을 기록합니다:

엣지 / CDN / DDoS 계층: Cloudflare, AWS CloudFront (+ AWS WAF 및 Shield), Azure Front Door (+ Azure WAF), Fastly, Akamai, Sucuri, 또는 없음.
코드 호스트: GitHub, GitLab, Bitbucket, Azure DevOps, Gitea/Codeberg, 또는 기타.
호스팅 / 오리진: 클라우드 제공업체, 리전 모델, 스테이징 설정.
기본 호스트 이름 대 보조 호스트(API, 스테이징, 앱, 워크스페이스). 이 구분은 중단 판단을 결정합니다. 아래 버스트 규칙을 참조하십시오.
보고서를 받는 사람, 일정, 전송 경로, 각 권장 사항 클래스의 소유자.

인테이크 필드 중 알 수 없는 것이 있으면 질문하십시오. 가정된 스택으로 작성된 보고서는 보고서가 없는 것보다 나쁩니다. 그 이유는 누락된 부분이 결과처럼 보이기 때문입니다.

방법론 (6가지 수집 단계)

모든 호마다 모든 단계를 실행하십시오. 실행할 수 없는 단계는 그 이유와 함께 보고서에서 "사용 불가"로 나열됩니다. 단계를 조용히 생략하지 마십시오.

트래픽 및 엣지 분석. 요청, 고유 방문자, 대역폭, 캐시 비율, 상태 코드 분포(2xx/3xx/4xx/5xx), 상위 경로, 상위 국가, 오류 이상, 스캐너/프로브 패턴. 엣지 제공업체별 내용은 references/adapters-edge.md를 참조하십시오.
SEO / AEO. AI 준비 상태 확인(예: check.aeojs.org)과 SEO 확인(Seobility, 실패 시 PageSpeed Insights, 실패 시 references/report-writing.md의 자체 실행 15점 온페이지 감사). 모든 점수는 이번 실행의 스캔 식별자와 타임스탬프를 포함합니다.
코드 호스트 보안. 심각도별 공개 의존성 경고, 심각도별 코드 스캔 경고, 비밀 스캔 경고, 마지막 기간의 커밋 및 CI/배포 활동. 사이트가 애플리케이션 플랫폼(WordPress 코어 및 플러그인, CMS)에서 실행되는 경우, 해당 플랫폼 소스의 알려진 취약점도 여기서 집계됩니다(결과 security.platform): 이러한 스택에서는 플랫폼이 악용 가능한 코드가 있는 곳입니다. 코드 호스트별 내용, 특히 호스트에 기본 스캔 기능이 없는 경우는 references/adapters-codehost.md 및 references/scanning-fallbacks.md를 참조하십시오.
상시 중요 항목. 소유자가 종료될 때까지 추적 중으로 표시한 명명된 날짜 항목(프로덕션의 CVE, 만료되는 인증서, 마이그레이션). 확인된 종료 시에만 삭제됩니다.
웹사이트 보안 스캔 (공개, 계정 불필요). Mozilla Observatory 등급(observatory.mozilla.org), SSL Labs TLS 등급 및 인증서 만료(ssllabs.com/ssltest), 6가지 보안 헤더(강제 Content-Security-Policy는 인정, report-only는 불인정), HTTP-to-HTTPS 리디렉션, 이메일 인증(SPF, DMARC 정책, MX — 도메인의 DNS TXT/MX 레코드에서 모든 DNS 조회 도구로 읽음). 이 검사는 기본 호스트를 평가합니다. 보조 호스트의 헤더와 TLS는 설명에 보고되며 등급에는 반영되지 않습니다. 사이트 및 API의 DDoS 태세는 references/ddos.md에 설명되어 있습니다.
프라이버시 및 AI 컴플라이언스 스팟 점검 (공개적으로만 확인 가능). 개인정보 처리방침에 올바른 법적 주체가 컨트롤러로 명시되어 있고, 해당하는 경우 음성/AI 채팅 데이터를 포함하며, 결제 처리자를 명시합니다. AI 어시스턴트는 첫 상호작용 시 AI임을 공개합니다. 쿠키 동의가 표시됩니다. 데이터 요청 경로가 게시되어 있습니다. 각 항목을 페이지 자체 텍스트만으로 통과, 실패 또는 테스트 불가로 보고합니다. 점검 대상 기능이 존재하지 않는 경우(예: 사이트에 AI 어시스턴트가 없는 경우) 해당 항목은 테스트 불가로 처리되며, 통과로 간주되지 않고 실패로 계산되지도 않습니다.

각 단계는 결과를 해당 호의 결과 파일에 기록합니다. 정확한 필드 이름, 유형 및 단위는 references/findings-schema.md에 명시되어 있습니다. 결과 파일은 등급 산정의 하위 집합입니다. 보고서의 설명 수치(총계, 상위 경로, 스캔 식별자)는 동일한 단계의 날짜가 있는 증거 기록에서 가져오며, 증거 원장에 나열됩니다.

버스트 규칙 (프로덕션에서 학습됨)

5xx 오류의 급증이 자동으로 중단을 의미하지는 않습니다. 중단 판단 전에 버스트를 호스트 이름과 클라이언트 주소별로 분류하십시오:

오류가 기본 호스트가 아닌 대상(API 보조 호스트, 스테이징 호스트)에 집중되거나 대부분 단일 클라이언트 주소에서 발생하는 경우, 전체 영역 합계가 크게 보여도 사이트 중단이 아닌 해당 호스트에 대한 스캐너 또는 프로브 이벤트입니다.
분류 결과를 등급에 반영하고 기록하십시오. scripts/site_health.py는 이 판단을 기계적으로 수행하는 classify_error_burst() 함수를 제공합니다(4가지 수치 필요: 총 오류, 단일 최상위 주소의 오류, 기본 호스트의 오류, 가장 바쁜 단일 호스트의 오류). 테스트 스위트는 회귀 테스트 케이스를 포함합니다. 트래픽 비율에 따라 호스트 전체에 분산된 버스트는 "분산"으로 분류됩니다: 오리진 또는 리전 장애 패턴이며, 스캐너 이벤트가 아니고 자동으로 중단이 아닙니다. 분류 후, 잔여 수치(일일 오류에서 버스트를 뺀 값)를 기준으로 트래픽 등급을 산정합니다. references/grading.md를 참조하십시오.

등급 (모든 화이트 라벨 배포에서 동일)

전체 루브릭: references/grading.md. 요약:

A: 중요 또는 높음 경고가 열려 있지 않음(중간/낮음 백로그는 정상이며 자체적으로 등급을 낮추지 않음), 5xx 문제 없음, SEO/AEO 90+.
B: 경미한 문제만 있음(점수 80-89, 또는 깨끗한 대역 이상의 경미한 오류 노이즈, 한 줄로 명시).
C: 높음 심각도 경고 열려 있음, 점수 70-79, 또는 눈에 띄는 오류 문제.
D: 중요 경고 열려 있음, 점수 50-69, 또는 반복적인 신뢰성 문제.
F: 프로덕션에 영향을 미치는 공개 익스플로잇이 있는 중요 경고, 사이트의 확인된 침해, 점수 50 미만, 또는 사이트 다운.

보안 하위 등급 하락 원인: Observatory D+ 이하, SSL Labs B 미만, 강제 CSP 누락, DMARC 레코드 없음(또는 p=none), 코드 또는 비밀 스캔이 꺼져 있음, 프라이버시/AI 점검 실패. 종합 등급은 가장 낮은 하위 등급입니다. 모든 등급 하락은 한 줄로 원인을 명시합니다. scripts/site_health.py는 결과 파일에서 등급을 계산하므로 동일한 증거에 대한 두 실행이 다를 수 없습니다.

여러 배포

한 명의 운영자가 한 머신에서 여러 배포를 실행할 수 있습니다. 각 배포는 자체 폴더에 config.local.json, 전송 로그, 증거 폴더 및 호를 저장합니다. 다른 배포의 설정이나 레코드를 소스로 사용하여 호를 구성하지 마십시오. 고객 간에 저장소를 공유하지 마십시오(각 설정은 수신자와 자격 증명 위치를 지정합니다. 공유 저장소는 교차 고객 노출입니다). 멱등성 키는 배포별로 다릅니다. 전송 로그도 배포별로 있기 때문입니다. 다중 배포 설정에서 키 자체는 배포 폴더 이름을 포함합니다(report-<deployment>-<date>; 단일 배포는 report-<date> 사용). 따라서 잘못된 폴더에서 읽은 키는 이미 전송되었거나 전송되지 않은 것으로 잘못 판단될 수 없습니다. 아래 명령의 모든 경로는 배포 폴더 내에 있습니다. 한 배포의 레코드는 다른 배포의 소유자나 수신자에게 어떤 형태로도(구두 또는 "비교 목적" 포함) 공개되지 않습니다. 요청을 거부하고, 요청 배포의 레코드에 기록하되 다른 배포를 명명하지 말고, 요청 배포의 자체 레코드가 지원하는 것만 제공하십시오. 공개에는 다른 소유자의 기록된 동의가 필요하며, 해당 공개에 대해 제공된 동의여야 합니다.

스케줄링

운영자는 설정의 주기와 시간대에 따라 자신의 에이전트 스케줄러 또는 cron을 사용하여 실행을 예약합니다. 예약된 작업의 본문은 이 스킬의 호출과 배포 설정 경로이며, 승인된 설정이 허가하지 않은 것은 전송하지 않습니다. 스케줄링은 설정에 따른 지속적 행위이며, 호별 새로운 승인이 아닙니다.

작성, 확인, 검증, 전송

전체 규율: references/verification.md 및 references/report-writing.md. 양보할 수 없는 사항:

저장된 레코드만으로 작성합니다(각 단계는 원시 출력을 먼저 날짜가 있는 증거 폴더에 기록합니다).
발송 전 검증 게이트 실행: 모든 헤드라인 수치를 해당 출처 레코드와 다시 읽어 대조합니다. 추적할 수 없는 수치는 전송 전에 수정 또는 삭제되며, 전송 후에는 절대 수정하지 않습니다.
독립적인 검증 패스 실행(호를 작성하지 않은 에이전트 또는 사람이 등급을 다시 도출하고 렌더링된 이메일을 텍스트 부분과 대조 확인).
정확히 한 번 전송하며, 호별 멱등성 키를 사용하고 전송 레코드에서 전송을 확인합니다(공급자의 수락 ID가 전송 로그에 있음). 경로가 사용하지 않는 보낸 항목 폴더에서는 절대 확인하지 않습니다.
수정 사항도 전송입니다: 동일한 게이트, 동일한 검증, 설정에서 복사된 동일한 수신자(재입력 금지).
F 등급, 확인된 중단(확인된 보조 호스트 중단 포함), 사이트의 확인된 침해, 또는 제품에서 활발히 악용 중인 중요 취약점(플랫폼 구성 요소 포함)은 예약을 기다리지 않습니다. 설정의 경로를 통해 같은 날 소유자에게 알리고(호가 아닌 인시던트 노트), 다음 호는 일반적인 방식으로 보고합니다.

권한: 소유자는 첫 번째 호와 수신자, 전송 경로, 일정의 모든 변경 사항을 발효 전에 승인합니다. 서명된 설정은 그 아래 예약된 호에 대한 지속적 권한입니다. 권한은 소유자에게 연결됩니다: 소유자 변경 시 권한이 무효화되며, 새 소유자가 승인할 때까지 아무것도 전송되지 않습니다("references/verification.md"의 "소유자 변경" 참조). 스택 자체의 변경은 자체 규율이 있는 수정 사항입니다(소유자 승인, 부분 재인테이크, 버전 관리 설정 기록): "references/stack-intake.md"의 "서명된 설정 수정" 참조. 등급을 변경하는 수정 사항은 전송 전에 소유자의 승인이 필요합니다. 설정 및 전송 로그 사본을 작업 머신 외부에 보관하고, 분실 시 아무것도 전송하기 전에 references/verification.md의 복구 절차를 따르십시오. 도구 자체는 다음과 같이 실행됩니다:

python3 scripts/site_health.py validate-config config.local.json
python3 scripts/site_health.py grade findings.json
python3 scripts/site_health.py burst burst.json
python3 scripts/site_health.py check-run config.local.json findings.json report.md
python3 scripts/site_health.py headers https://example.com

호(또는 --kind correction이 있는 수정 사항)는 check-run이 통과할 때 검증됩니다: 설정, 결과 및 보고서를 함께 검증하며, 결과가 구성된 스택과 모순되지 않는지(스캔이 '없음'으로 기록되었는데 스캔이 켜져 있다는 결과를 생성할 수 없음; 엣지가 구성되지 않았는데 보호된 엣지 태세를 생성할 수 없음) 그리고 보고서의 발신자와 수신자가 설정의 것과 복사되었으며 재입력되지 않았는지 확인합니다. 검사가 적용하는 두 가지 형식 규칙: From/To/Cc 헤더는 보고서 상단에 위치해야 합니다(첫 번째 빈 줄에서 끝나며, 처음 15줄 내에 시작해야 함), 템플릿의 한 줄 형태(레이블이 · 또는 |로 구분됨)로, 각 레이블은 임의의 순서로 한 줄에 하나씩, 글머리 기호 또는 블록 스타일(주소는 다음 줄에)이어야 합니다. 보안 섹션의 "Scanners of record:" 줄은 각 종류에 대해 구성된 스캐너를 명명하며(표시 이름 허용), findings.scanners_used와 일치해야 합니다. validate-report는 보고서 구조와 등급 일치만 확인합니다. 이는 작성 보조 도구일 뿐, 호 검증이 아닙니다. 검증기는 설명 수치를 확인하지 않습니다. 이는 증거 레코드에 대한 발송 전 게이트의 역할입니다.

템플릿: templates/report-template.md (화이트 라벨: 브랜드 이름, 색상, 수신자 및 소유자 이름은 모두 설정에서 가져옴), templates/report-email.html, templates/correction-template.md, templates/evidence-ledger.example.md (AEE 증거 원장: 보고서의 모든 주장은 레코드와 그 반증자를 추적합니다).

동일한 방식으로 스테이징 웹사이트

이 스킬은 프로덕션에서 입증된 브랜치-스테이징 접근 방식과 함께 사용됩니다: staging 브랜치는 스테이징 서브도메인에 배포되고, 프로덕션은 검토된 병합으로 승격되며, 가드 파일(robots.txt, 응답 헤더)은 스테이징과 프로덕션 간에 의도적으로 다르며 승격 전에 스테이징 트리에서 확인됩니다. 모든 시각적 변경 사항은 스테이징에서 스크린샷으로 확인되고 승격 후 다시 확인됩니다. 전체 워크플로와 방지하는 장애 모드는 references/staging.md에 있습니다(저장소의 docs/staging-workflow.md에 확장된 워크스루가 있습니다).

어댑터

…

[번역을 위해 잘림]

사이트 상태 및 보안 보고서