Showing Posts From
모의해킹
- 06 Dec, 2025
OWASP Top 10을 외우는 것보다 중요한 것들
OWASP Top 10을 외우는 것보다 중요한 것들 외워봤자 뭐하나 OWASP Top 10 외웠다. SQL Injection, XSS, CSRF, 다 안다. 그런데 실무에서 막상 마주하면 못 찾는다. 신입 때 착각했다. OWASP Top 10만 외우면 보안 QA 끝인 줄. 실전은 달랐다. 취약점이 그렇게 교과서처럼 나오지 않는다. 변형되어 있고, 숨어 있고, 조합되어 있다. 첫 프로젝트 생각난다. SQL Injection 찾으라고 했다. 당연히 'OR 1=1-- 입력하면 되겠지' 했다. 안 터졌다. WAF가 막았다. 그다음은? 몰랐다. 선배가 인코딩 우회 보여줬다. 'UNION SELECT 대신 %55NION %53ELECT' 이런 식. 그때 깨달았다. 리스트 외우는 건 시작일 뿐이다.OWASP Top 10은 가이드다. 지도가 아니다. 지도는 따라가면 목적지 도착한다. 가이드는 방향만 알려준다. 길은 직접 찾아야 한다. 보안 QA 4년 하면서 느낀 거. 진짜 중요한 건 따로 있다. 이론보다 먼저 알았어야 할 것들. 선배들이 알려주지 않았던 것들. 지금부터 적는다. HTTP를 진짜 이해하는가 보안 테스트의 90%는 HTTP다. 웹 애플리케이션 진단이니까. 그런데 HTTP를 제대로 아는 보안 QA가 많지 않다. Request와 Response 구조. Header와 Body. Cookie의 동작 원리. Session 관리 방식. 이게 기본이다. 근데 이것도 모르고 Burp Suite 돌리는 사람 많다. 예를 들어본다. XSS를 찾는다고 하자. <script>alert(1)</script> 입력한다. 안 된다. Content-Type이 application/json이라서다. JSON에선 HTML 태그가 안 먹힌다. 그럼 어떻게? Content-Type을 text/html로 바꿔보거나, JSON 구조 내에서 실행 가능한 페이로드를 만들어야 한다.작년에 있었던 일. 신입이 "SQL Injection 안 되는데요" 했다. 봤더니 GET 파라미터만 테스트했다. POST Body는? Cookie는? Header는? 다 확인해야 한다. 그런데 HTTP 구조를 모르면 어디를 봐야 할지 모른다. 또 있다. Authentication vs Authorization. 인증과 인가. 헷갈리는 사람 많다. 인증은 "너 누구야?" 확인하는 거다. 인가는 "너 이거 할 권한 있어?" 확인하는 거다. 둘은 다르다. 로그인했다고(인증) 다른 사람 정보 볼 수 있는 건(인가) 아니다. 실제로 IDOR(Insecure Direct Object Reference) 취약점 많다. /api/user/123 이런 식. 내 ID가 123인데, 124로 바꾸면 다른 사람 정보 나온다. 인증은 되어 있다. 근데 인가 체크가 없다. 이게 구분 안 되면 못 찾는다. HTTP 상태 코드도 중요하다. 200, 302, 401, 403, 500. 각각이 뭘 의미하는지. 보안 관점에서 뭘 시사하는지. 302 Redirect 많이 나오면? 인증 로직 우회 가능성 있다. 401 Unauthorized랑 403 Forbidden 차이는? 401은 인증 안 됨. 403은 인증은 됐는데 권한 없음. 에러 메시지 다르게 나오면 계정 탐색(Account Enumeration) 가능하다. 프로토콜 레벨에서 이해해야 한다. OSI 7계층까지는 아니어도, Application Layer는 확실히. TCP 핸드셰이크, TLS 동작, DNS 조회. 이런 거 모르면 Man-in-the-Middle 공격 이해 안 된다. Burp Suite 쓰는 이유가 뭔가? HTTP 트래픽을 가로채서 조작하기 위해서다. 근데 HTTP를 모르면 뭘 조작해야 할지 모른다. 도구는 도구일 뿐이다. 개발을 조금이라도 할 줄 아는가 보안 QA가 코딩 못 해도 되나? 아니다. 절대 아니다. 스크립트는 필수다. Python, Bash, 뭐든 하나는 해야 한다. 자동화 안 하면 시간 부족하다. 수동으로 일일이 하면 하루 종일 걸린다. 예를 들어본다. API 엔드포인트 100개 있다. 각각 IDOR 취약점 체크해야 한다. 수동으로? 미친 짓이다. 스크립트 짜서 돌린다. 10분이면 끝난다. for user_id in range(1, 1000): response = requests.get(f'/api/user/{user_id}') if response.status_code == 200: check_unauthorized_access(response)이런 거다. 간단하다. 근데 코딩 모르면 못 한다. 더 중요한 건 코드 리뷰다. 개발자가 짠 코드 봐야 한다. 설계 단계에서 취약점 찾는 게 제일 효율적이다. 배포 후 찾으면 고치는 데 비용 10배다. 코드 보면 보인다. "여기 입력값 검증 안 하네", "SQL 쿼리 하드코딩했네", "시크릿 키 평문으로 박았네". 근데 코드 못 읽으면? 블랙박스 테스트만 한다. 시간 오래 걸리고 놓치는 것도 많다. 프레임워크 지식도 필요하다. Spring, Django, Express. 각각 보안 메커니즘이 다르다. Spring Security 어떻게 동작하나? Django의 CSRF 토큰은? Express의 미들웨어 순서는? 작년에 Django 앱 진단했다. CSRF 토큰 있었다. 근데 검증 로직을 개발자가 직접 짰다. 틀렸다. Django 내장 기능 안 쓰고 자기가 만들었다. 당연히 우회됐다. 코드 봤기 때문에 찾았다. 정규표현식도 알아야 한다. ReDoS(Regular Expression Denial of Service) 취약점 있다. (a+)+$ 이런 패턴에 "aaaaaaaaaaaaaaaaaa!" 입력하면 서버 뻗는다. 백트래킹 때문이다. 코드에서 정규식 보면 체크한다. Git도 봐야 한다. 커밋 히스토리에 시크릿 키 있다. 지웠어도 히스토리엔 남는다. .git 폴더 노출되면 전체 소스 다운받는다. 이것도 개발 흐름 이해해야 찾는다. 물론 풀스택 개발자 될 필요는 없다. 그냥 읽을 줄 알면 된다. 그리고 간단한 스크립트 짤 줄 알면 된다. 근데 이게 생각보다 큰 차이 만든다. 비즈니스 로직을 이해하는가 기술적 취약점만 찾으면 되나? 아니다. 비즈니스 로직 취약점이 더 치명적이다. SQL Injection으로 DB 털어도, 비즈니스 로직 허점으로 돈 빼가는 게 더 무섭다. 실제로 그런 케이스 많다. 예를 들어본다. 쿠폰 중복 사용. 로직상으로 한 번만 써야 한다. 근데 동시에 두 번 요청하면? Race Condition 발생한다. 쿠폰이 두 번 적용된다. 기술적으로 취약점 아니다. 근데 비즈니스적으론 큰 문제다. 핀테크라서 결제 로직 많이 본다. 취약점 많다. 환불 로직: 금액 검증 안 함. 100원 결제하고 1000원 환불 요청. 포인트 충전: 음수 입력. -1000원 충전하면 포인트 늘어남. 할인 쿠폰: 쿠폰 코드 예측 가능. COUPON001, COUPON002... 추천인 보상: 자기 자신 추천인으로 등록.이런 거 OWASP Top 10에 없다. 근데 실제로 돈 나간다. 테스트할 때 시나리오 짠다. "사용자가 이걸 악용하려면 어떻게 할까?" 공격자 마인드로 생각한다.정상 플로우 이해 경계값 테스트 (음수, 0, 최댓값) 순서 바꾸기 (3단계를 1단계보다 먼저) 동시 요청 (Race Condition) 반복 실행 (Rate Limiting 체크)지난주에 있었던 일. 송금 기능 테스트했다. 정상 플로우는 문제없었다. 그런데 "송금 중" 상태에서 취소 누르면? 돈은 빠져나갔는데 취소 처리됐다. 이중 지불 문제다. 기술적 취약점 아니다. 상태 관리 로직 문제다. 또 있다. 권한 관리. 일반 사용자가 관리자 기능 호출하면? API 레벨에서 막아야 한다. 근데 프론트엔드에서만 숨겨놓은 경우 많다. URL 직접 치면 들어가진다. 비즈니스 로직 이해하려면 기획서 봐야 한다. 개발자랑 얘기해야 한다. "이 기능 왜 이렇게 만들었어요?" 물어본다. 맥락 이해해야 허점 보인다. OWASP Top 10은 기술 중심이다. 근데 실제 사고는 비즈니스 로직에서 많이 난다. 이거 놓치면 안 된다. 방어자 관점만 가지고 있지 않은가 보안 QA는 공격자처럼 생각해야 한다. 방어만 생각하면 못 뚫는다. 개발자는 기능 만든다. "이렇게 쓰면 되겠지" 생각한다. 근데 공격자는? "이거 어떻게 악용하지?" 생각한다. 우리도 그래야 한다. 예를 들어본다. 파일 업로드 기능. 개발자는 "이미지만 올리겠지" 생각한다. 확장자 체크만 한다. .jpg, .png만 허용. 끝. 근데 공격자는? shell.php.jpg 올린다. 또는 shell.jpg인데 내용은 PHP 코드. MIME Type 속인다. 더블 익스텐션, Null Byte Injection, Content-Type 조작. 방법 많다. 공격 기법 공부해야 한다. 실제로 해보는 게 제일 좋다. 집에 랩 환경 있다. VirtualBox에 Kali Linux, DVWA(Damn Vulnerable Web App), WebGoat 돌린다. 여기서 연습한다. SQL Injection 어떻게 하는지, XSS 페이로드 어떻게 만드는지, RCE(Remote Code Execution) 어떻게 달성하는지. 이론으로만 알면 안 된다. 직접 해봐야 한다. sqlmap 돌려보고, msfvenom으로 페이로드 만들어보고, Reverse Shell 따보고. 그래야 감이 온다. CTF(Capture The Flag) 대회 자주 나간다. 한 달에 두 번 정도. Hack The Box, TryHackMe에서도 문제 푼다. 실력 유지에 좋다. 새로운 기법도 배운다. 지난달 CTF에서 배운 거. XXE(XML External Entity) 취약점. XML 파서가 외부 엔티티 처리할 때 생긴다. 파일 읽기, SSRF(Server-Side Request Forgery) 가능하다. 이론으론 알았다. 근데 실제로 exploit 작성하니까 확실히 이해됐다. 공격 도구도 써봐야 한다. Burp Suite, OWASP ZAP, Nmap, Nikto, SQLMap, John the Ripper, Hashcat. 각각 언제 쓰는지, 어떻게 쓰는지 알아야 한다. 근데 조심해야 한다. 회사 시스템에 함부로 쓰면 안 된다. 허가받고 테스트한다. 모의해킹 계약서 쓴다. 범위 명확히 한다. 실수로 서비스 터뜨리면 큰일이다. 작년에 있었던 일. 취약점 스캐닝 돌렸다. 스레드 너무 많이 설정했다. 서버 부하 급증. 서비스 느려졌다. 다행히 새벽이라 사용자 적었다. 그 후로 항상 테스트 환경 먼저 확인한다. 공격자 마인드셋. 이게 핵심이다. "여기서 뭘 뽑아낼 수 있을까?", "이거 우회하려면?", "이 기능 연계하면 더 큰 공격 되나?" 이렇게 생각한다. 커뮤니케이션을 할 줄 아는가 기술만 잘해서 되나? 아니다. 말을 잘해야 한다. 취약점 찾았다. 끝? 아니다. 개발자한테 전달해야 한다. 그것도 제대로. "여기 취약점 있어요" 이렇게 말하면? "뭐가 문제인데요?" 돌아온다. 리포트 쓰는 게 중요하다. 구조는 이렇다.취약점 이름: SQL Injection 위치: /api/login, username 파라미터 심각도: Critical (CVSS 9.8) 재현 방법: 스텝바이스텝, 스크린샷 첨부 영향: DB 전체 조회 가능, 계정 탈취 가능 해결 방안: Prepared Statement 사용, 입력값 검증 강화구체적이어야 한다. "보안 취약점 있음" 이건 쓰레기다. "사용자 입력값이 SQL 쿼리에 직접 삽입되어 공격자가 임의의 SQL 명령 실행 가능" 이게 리포트다. 재현 방법이 제일 중요하다. 개발자가 똑같이 해봐야 한다. 안 되면? "재현 안 되는데요?" 하면서 안 고친다. 1. Burp Suite에서 /api/login POST 요청 캡처 2. username 파라미터 값을 admin' OR '1'='1 로 변경 3. 요청 전송 4. 200 OK 응답, 관리자 계정으로 로그인 성공이렇게 적는다. 따라 하기만 하면 되게. 심각도 평가도 중요하다. CVSS(Common Vulnerability Scoring System) 쓴다. 숫자로 표현한다. 9.0 이상이면 Critical. 7.0~8.9면 High. 개발자가 우선순위 정할 수 있다. 근데 가끔 싸운다. "이거 Critical 아닌데요?" 한다. "실제 환경에서 exploit 어렵잖아요?" 그럼 설명해야 한다. "WAF 없으면 바로 뚫립니다", "실제 사례 있습니다". 근거 있어야 한다. 말투도 중요하다. "여기 취약점 있는데 왜 이렇게 짰어요?" 이러면 적 만든다. "여기 보안 이슈가 있는데, 같이 해결 방법 찾아볼까요?" 이게 맞다. 개발자는 적이 아니다. 같은 팀이다. 서비스 안전하게 만드는 게 공동 목표다. 그거 잊으면 안 된다. 회의 때 발표도 한다. 경영진한테 보안 현황 보고한다. 기술 용어 쓰면 안 된다. "SQL Injection이..." 하면 졸린다. "공격자가 고객 개인정보 전부 빼갈 수 있습니다" 이래야 귀 기울인다. 숫자로 말한다. "취약점 50개 발견, 그중 Critical 5개, 2주 내 패치 필요" 이렇게. 구체적이고 액션 가능하게. 커뮤니케이션 못 하는 보안 QA? 아무리 실력 좋아도 쓸모없다. 찾아도 전달 못 하면 의미 없다. 최신 트렌드를 따라가고 있는가 보안은 계속 변한다. 작년 방어법이 올해 안 통한다. 매일 아침 루틴이 있다. 출근하면 제일 먼저 보안 뉴스 체크한다.The Hacker News Krebs on Security r/netsec (Reddit) Twitter에서 보안 전문가들 팔로우CVE(Common Vulnerabilities and Exposures) 업데이트 본다. 새로운 취약점 나왔나 확인한다. 우리 회사 쓰는 라이브러리에 해당되나 체크한다. 예를 들어본다. Log4j 취약점(CVE-2021-44228). Log4Shell이라고 불렸다. 전 세계 난리났다. 우리도 긴급 점검했다. Java 쓰는 모든 서비스 체크했다. 다행히 해당 버전 안 썼다. 근데 모니터링은 계속했다. 이런 거 놓치면? 당한다. 실제로 Log4j 취약점으로 털린 회사 많다. 패치 늦었기 때문이다. 기술 스택 변화도 따라가야 한다. 요즘 클라우드 많이 쓴다. AWS, GCP, Azure. 각각 보안 설정 다르다. S3 버킷 권한, IAM 정책, Security Group. 이거 제대로 설정 안 하면 데이터 유출된다. 컨테이너 보안도 있다. Docker, Kubernetes. 이미지 스캔, 런타임 보안, 네트워크 폴리시. 새로운 영역이다. 공부해야 한다. API 많아졌다. REST, GraphQL. GraphQL은 복잡하다. 쿼리 깊이 제한 안 하면 DoS 된다. Introspection 노출되면 스키마 전체 보인다. 이것도 새로 배웠다. AI/ML 서비스도 나온다. Prompt Injection, Model Inversion, Data Poisoning. 완전히 새로운 공격 벡터다. 아직 연구 단계지만 알아야 한다. 공부 방법은 여러 가지다.온라인 강의: Udemy, Coursera, Pluralsight 책: "The Web Application Hacker's Handbook" (좀 오래됐지만 클래식) 컨퍼런스: DEFCON, Black Hat (비싸서 유튜브로 본다) 웨비나: OWASP Chapter 미팅 참석 블로그: 보안 전문가들 글 읽기자격증도 있다. CEH(Certified Ethical Hacker), OSCP(Offensive Security Certified Professional), CISSP. 나는 CEH 있다. OSCP 준비 중이다. 실습 많아서 힘들다. 근데 배우는 거 많다. 시간 투자해야 한다. 퇴근 후 1시간, 주말에 3시간 정도. 안 하면 뒤처진다. 보안 분야는 특히 빠르다. 가끔 지친다. "또 새로운 거 나왔네" 싶다. 근데 어쩔 수 없다. 이게 이 일이다. 좋아하지 않으면 못 한다. 실무에서 부딪히는 진짜 문제들 이론은 깨끗하다. 실무는 지저분하다. 리포트 써서 올린다. "Critical 취약점 5개 발견" 한다. 개발팀 반응은? "다음 스프린트에 처리할게요". 다음 스프린트? 2주 뒤다. 그사이 뚫리면? 모른다. 우선순위 싸움 많다. 개발팀은 기능 개발이 우선이다. 보안은? 나중이다. "지금 당장 문제 없잖아요" 한다. 터져봐야 안다. 작년에 있었던 일. IDOR 취약점 찾았다. 다른 사람 주문 내역 볼 수 있었다. High 심각도로 리포트했다. 2달 뒤에 고쳤다. 왜? "다른 기능 개발 중이라서요". 이해는 한다. 근데 답답하다. 리소스 부족도 문제다. 보안팀이 나 포함 3명이다. 개발팀은 30명. 모든 기능 다 보기 힘들다. 샘플링한다. 중요한 거 위주로. 놓치는 거 있을 수밖에. False Positive 문제도 있다. 자동화 스캐닝 돌리면 취약점 수백 개 나온다. 근데 반은 오탐이다. 일일이 확인해야 한다. 시간 엄청 걸린다. 그래서 요즘은 SAST(Static Application Security Testing), DAST(Dynamic Application Security Testing) 도구 쓴다. SonarQube, Checkmarx, Veracode. 자동화한다. 근데 이것도 튜닝 필요하다. 룰 설정 안 하면 노이즈 많다. 개발자 교육도 해야 한다. 근본 해결은 처음부터 안전하게 짜는 거다. Secure Coding 교
- 03 Dec, 2025
월요일 아침 9시, 출근하자마자 CVE 뉴스 체크하는 이유
월요일 9시 출근했다. 커피 한 잔 놓고 컴퓨터 켰다. 노트북 부팅되는 동안 폰으로 CVE 피드 먼저 확인한다. 습관이다. 6년째. 주말 동안 올라온 CVE가 12건. 그중 Critical 2건, High 5건. 심장이 쿵 내려앉는다. Spring Framework 취약점. RCE. 우리 서비스 Spring 쓴다. 버전 확인부터 해야 한다.왜 월요일이 제일 긴장되나 금요일 저녁에 해커들이 취약점 터뜨린다. 주말 동안 패치 안 나온다. 월요일 아침에 세상이 바뀌어 있다. 작년 12월에 Log4j 터졌을 때. 금요일 밤 11시였다. 주말 내내 비상 근무했다. 그 기억 때문에 월요일이 무섭다. 주말 동안 뭔가 터지지 않았을까. 우리 서비스가 뚫리지 않았을까. 체크리스트가 머릿속에 있다.CVE 데이터베이스 NVD 피드 보안 커뮤니티 (Reddit, Twitter) 회사 사용 기술 스택 리스트 벤더 보안 공지30분이면 다 본다. 근데 30분이 제일 긴장된다. Spring RCE 취약점 확인 CVE-2024-XXXX. Spring Framework 6.0.15 이하 버전. 원격 코드 실행 가능. 우리 버전은? 재빨리 pom.xml 확인한다. 6.0.13. 망했다. CVSS 점수 9.8. POC 코드가 벌써 깃허브에 올라왔다. 누구나 공격 가능하다는 뜻이다. 바로 개발팀장한테 슬랙 보낸다. "긴급. Spring RCE 취약점. 우리 버전 해당됨." 5분 만에 답장 온다. "회의 중. 10시에 보자." 회의가 중요한가, 서비스 보안이 중요한가. 속으로 욕 나온다.취약점 영향도 분석 회의 끝날 때까지 혼자 분석한다. 우리 서비스 어디에 Spring 쓰는지. API 서버, 백오피스, 배치 시스템. 전부다. 공격 벡터 확인한다. HTTP 요청으로 실행 가능. 인증 없이도 된다. 최악이다. POC 코드 로컬에서 돌려본다. 테스트 서버에 대고. 5초 만에 쉘 땄다. 이거 실제로 공격당하면? 고객 데이터 전부 털린다. 금융 서비스인데. 등에 식은땀 난다. 빠르게 리포트 작성한다.취약점 개요 영향받는 시스템 목록 공격 가능성 (매우 높음) 예상 피해 규모 긴급 패치 권고10시 되자마자 개발팀장 자리로 간다. "이거 봐야 합니다. 지금 당장." 개발팀과의 줄다리기 개발팀장이 리포트 본다. 표정이 굳는다. "패치하면 되는 거 아냐?" "네. 근데 지금 해야 합니다." "배포 일정이 목요일인데." "목요일까지 기다리면 위험합니다." 항상 이런 식이다. 보안팀은 급하다고 한다. 개발팀은 일정이 있다고 한다. "테스트는 했어?" "로컬에서 POC 돌려봤습니다." "그게 테스트야?" 화가 나지만 참는다. 설득해야 한다. "지금 POC 코드가 공개됐습니다. 누구나 공격 가능합니다. CVSS 9.8은 최고 위험도입니다. 우리 API 서버 전부 노출돼 있습니다." 개발팀장이 한숨 쉰다. "오늘 중으로 패치하고 내일 새벽 배포." "감사합니다." 겨우 설득했다.패치와 검증 개발팀이 Spring 버전 올린다. 6.0.16. 취약점 수정된 버전이다. 근데 버전만 올린다고 끝이 아니다. 의존성 체크해야 한다. 다른 라이브러리랑 충돌 없는지. 빌드 에러 3번 났다. lombok, querydsl 버전 문제. 2시간 걸렸다. 오후 3시에 스테이징 배포. 바로 취약점 스캔 돌린다. Burp Suite로 수동 테스트도 한다. POC 코드 다시 돌려본다. 안 뚫린다. 패치 성공했다. 안도의 한숨 나온다. 근데 프로덕션 배포는 내일 새벽 2시. 트래픽 적을 때. 그때까지 우리 서비스는 취약하다. 불안하다. 왜 CVE 체크가 중요한가 보안팀 없는 회사도 많다. 그럼 누가 CVE 체크하나. 아무도 안 한다. Log4j 터졌을 때. 전 세계 수십만 서비스가 뚫렸다. CVE 모니터링 안 한 회사들이다. 취약점은 공개되는 순간부터 시간 싸움이다. 해커들은 CVE 나오자마자 스캔 돌린다. 자동화돼 있다. 우리가 패치하기 전에 공격당할 수 있다. 먼저 아는 게 중요하다. 매일 아침 CVE 체크하는 이유다. 특히 월요일은 주말치 몰아서 본다. 30분 투자로 회사 지킨다. 루틴의 힘 6년 동안 하루도 안 빠지고 체크했다. 출장 가도 호텔에서 본다. 휴가 중에도 폰으로 확인한다. 동료들은 집착 아니냐고 한다. 근데 딱 한 번이라도 놓치면? 그날 터질 수 있다. 작년에 Confluence 취약점 나왔을 때. 우리 회사 Confluence 쓴다. CVE 확인하고 1시간 만에 서버 내렸다. 다음날 뉴스 봤다. 같은 취약점으로 3개 회사 해킹당했다. 우리는 살았다. 루틴이 회사 살렸다. 체크리스트는 단순하다.NVD 피드 확인 회사 기술 스택 매칭 영향도 분석 긴급도 판단 개발팀 공유30분이면 된다. 근데 이 30분이 회사를 지킨다. 보안 뉴스 소스들 내가 보는 소스는 정해져 있다. NVD (National Vulnerability Database). 미국 정부 운영. 모든 CVE가 여기 올라온다. CVE Details. CVE를 제품별로 정리해놨다. 우리 회사 쓰는 제품 검색하면 바로 나온다. Reddit r/netsec. 보안 커뮤니티. 여기서 핫한 취약점 먼저 알 수 있다. Twitter 보안 계정들. @GossiTheDog, @vxunderground 같은. 속보가 제일 빠르다. 각 벤더 보안 공지. Oracle, Microsoft, Apache 등. 이메일 알림 설정해놨다. 회사 Slack에 보안 채널 만들었다. RSS 피드 연동해서 자동으로 올라온다. 개발팀도 볼 수 있게. 정보는 많다. 필터링이 중요하다. 우리 회사 관련된 것만 집중한다. 오늘의 교훈 저녁 6시. Spring 패치된 버전 프로덕션 대기 중이다. 내일 새벽 2시 배포. 그때까지 WAF 룰 추가로 설정했다. 혹시 모를 공격 막기 위해. 퇴근하면서 생각한다. 오늘도 무사히 넘겼다. 내일 또 체크해야지. 월요일이 항상 긴장되는 이유. 주말 동안 세상이 바뀌니까. 해커는 쉬지 않으니까. CVE 체크는 루틴이다. 습관이다. 생존 본능이다. 9시 출근해서 제일 먼저 하는 일. 커피 내리고 CVE 확인. 6년째 똑같다. 앞으로도 똑같을 거다. 이게 내 일이니까.오늘도 무사히. 내일도 체크. 루틴이 날 지킨다.