SECURITY.APP · SOC
보안센터
취약점공격자가 파고들 수 있는, 코드나 설정의 허술한 지점입니다.
펜테스트허가를 받고 실제로 공격해 보며 뚫리는지 확인하는 점검입니다.
OWASP웹 보안 취약점을 분류해 공개하는 국제 비영리 단체이자 그 분류 체계입니다.
SECURITY · BUILD + HARDEN
코드는 보안 전문가가 한 줄씩 직접 읽습니다.
AI로 빠르게 만들면 서비스는 돌아가는데, 어디가 약한지는 만든 사람도 모르는 경우가 많습니다. byteforce 보안센터는 그 약한 곳을 공격자보다 먼저 찾아, 사고로 번지기 전에 막습니다. 한 번 보고 끝내지 않고, 배포할 때마다 다시 봅니다.
짐작으로 판단하지 않습니다. 어디가 어떻게 뚫리는지 직접 재현해 보여 드립니다.
코드는 자동 도구가 아니라 byteforce 화이트해커 네 팀이 직접 분석합니다.
MANUAL CODE REVIEW
화이트해커 네 팀이 읽고, 뚫고, 막고, 지킵니다.
byteforce 보안센터는 현직 화이트해커와 보안 전문가로 이뤄진 네 개의 팀이 코드를 직접 봅니다. 도구가 의심되는 곳을 표시하면, 사람이 그 자리를 직접 공격해 확인합니다.
- ACTIVE읽기도구 출력이 아니라 코드 원문을 한 줄씩 읽습니다.
- ACTIVE뚫기직접 공격해 보고 진짜 위험한 곳만 추려냅니다.
- ACTIVE막기그대로 재현되는 PoC와 구체적인 조치 방법을 줍니다.
- ACTIVE지키기배포할 때마다 같은 기준으로 다시 봅니다.
네 팀의 배경은 세 갈래입니다.
- PEDIGREE 01넥슨 출신대규모 게임 서비스 보안을 다뤄 온 경험.
- PEDIGREE 02DEF CON미국 라스베이거스, 세계 최대 해킹 컨퍼런스 무대 경력.
- PEDIGREE 03현직 보안업체지금도 보안 현장에서 일하는 전문가.
WHAT WE LOOK FOR · ATTACK SURFACE
점검할 때 실제로 들여다보는 공격면입니다.
취약점은 이미 잘 정리된 분류 체계가 있습니다. byteforce는 코드와 인프라에서 공격이 들어올 수 있는 지점을 여섯 갈래로 나눠 점검합니다. 각 갈래에서 무엇을 찾는지, 공개된 취약점 분류 명칭 그대로 정리했습니다. 칩을 누르면 각 분류의 해설이 열립니다.
공격면 여섯 갈래 — 인젝션, 크로스사이트, 접근 통제, 서버측, 시크릿·인프라, 악성·지속 — 의 공개 취약점 분류 목록입니다. 각 분류 칩을 누르면 정의·공격 방식·점검 항목 해설이 다이얼로그로 열립니다. 포렌식 프로브가 각 갈래를 차례로 훑는 도식은 장식이며, 아래 목록이 동일한 내용을 담습니다.
- 인젝션
- 크로스사이트
- 접근 통제
- 서버측
- 시크릿 · 인프라
- 악성 · 지속
분류·기법 명칭은 OWASP Top 10 · CWE · OWASP ASVS 같은 공개 표준에서 가져왔습니다. 여기 적힌 항목은 점검 범위이고, 어떤 취약점이 실제로 있는지는 점검해 봐야 알 수 있습니다.
약 45%AI가 생성한 코드에서 보안 결함이 발견된다는 보고가 있습니다.Veracode, 2025
바이브코딩은 생각한 것을 바로 코드로 만들어 줍니다. 빠른 대신 보안은 도구 기본값에 맡겨지기 쉽습니다. API 키가 클라이언트에 남고, 권한 검사가 서버에서 빠지고, 위험한 입력이 검증 없이 그대로 들어갑니다. 화면상으로는 잘 돌아가 보이기 때문에, 뚫리는 곳은 배포한 뒤에야 드러나는 경우가 많습니다. 사용자 데이터가 새거나 서비스가 멈춘 다음에 알게 되면, 그때는 운영에 바로 차질이 생깁니다.
이런 결함은 자동 스캔만으로는 다 걸러지지 않습니다. 스캐너가 의심되는 곳을 모아 줘도, 그게 진짜 뚫리는지는 사람이 직접 공격해 봐야 압니다.
바이브코딩에서 자주 터지는 곳
점검 항목 5건| 번호 | 위협 | 내용 |
|---|---|---|
| SEC-01 | 하드코딩 시크릿 | 클라이언트 JS 번들에 그대로 노출된 Stripe·OpenAI·Supabase API 키. |
| SEC-02 | RLS 누락 | Supabase·Firebase에서 Row Level Security를 켜지 않아 남의 행까지 읽히는 테이블. |
| SEC-03 | 인젝션 | 검증 없이 그대로 들어가는 입력으로 SQL·명령·XSS가 실행되는 경우. |
| SEC-04 | 취약한 의존성 | 알려진 CVE가 있는 패키지를 그대로 들고 배포한 상태. |
| SEC-05 | 인증·인가 누락 | 로그인은 있는데 권한 검사가 서버에 없어 호출만으로 통과되는 엔드포인트. |
분류 기준은 공개된 AI 코드 취약점 리포트(OX Security · Veracode 등)를 따릅니다.
app.post("/login", (req, res) => {const { id, pw } = req.bodyconst q = "SELECT * FROM users " +"WHERE id = '" + id + "'"db.query(q, (rows) => {const KEY = "sk_live_9f3a2c8b"log(rows)res.json(rows)})})
자동 스캐너와 사람은 뭐가 다를까요? 실제 코드 한 조각으로 한 장면씩 봅니다.
자동 스캐너는 의심되는 곳까지만 표시합니다. 그게 진짜 뚫리는지는 위 네 팀이 직접 공격해 보고 가려냅니다.
안 보면 치르는 비용
- 비대칭공격자는 뚫을 곳을 하나만 찾으면 되지만, 방어하는 쪽은 모든 곳을 다 막아야 합니다. 처음부터 불리한 싸움입니다.
- 침묵이미 뚫린 상태라도 겉으로는 멀쩡하게 돌아갑니다. 점검해 보기 전까지는 열려 있는지 알 수 없습니다.
- 누적배포할 때마다 새로 공격당할 수 있는 지점이 늘어납니다. 점검하지 않으면 그만큼 계속 쌓입니다.
- AI 코드AI로 빠르게 만든 코드일수록 보안을 신경 쓸 틈이 없어, 취약점이 그대로 남는 경우가 많습니다.
KILL CHAIN INTERDICTION
공격은 한 번에 오지 않습니다. 단계로 옵니다.
침해는 정찰에서 시작해 침투와 권한 상승을 거쳐 자리를 잡고, 데이터를 들고 나갑니다. 정찰 단계에서 차단하면 침투는 시작조차 못 합니다 — byteforce는 늦어도 권한 상승 직후, 공격자가 자리를 잡기 전에 이 사슬을 끊습니다.
- KILL01정찰공격면을 훑어 들어갈 틈을 찾습니다.이 단계의 분류: 노출된 .env, 노출된 관리자 경로, 보안 헤더 누락, 잘못된 CORS.
- KILL02침투검증 안 된 입력으로 경계를 넘습니다.이 단계의 분류: SQLi, XSS, SSRF, Path Traversal, XXE.
- KILL03권한 상승낮은 권한에서 더 높은 권한으로 올라섭니다.이 단계의 분류: Broken Access Control, IDOR, JWT 취약점, 인가 우회.
- KILL04지속다시 들어올 통로를 남겨 자리를 지킵니다.이 단계의 분류: Backdoor, Webshell, Rootkit, Insecure Deserialization.
- KILL05유출데이터를 들고 빠져나갑니다.이 단계의 분류: RCE, 하드코딩 시크릿, RLS 누락, Supply Chain.
앞 단계에서 끊을수록 복구할 것이 적습니다. 그래서 정찰·침투 단계에서 공격에 쓰이는 곳, 즉 노출된 시크릿, 검증 안 된 입력, 잘못된 접근 통제를 먼저 봅니다.
단계와 분류 명칭은 공개된 보안 표준인 OWASP Top 10 · CWE · OWASP ASVS를 따릅니다.
쉽게 말해해커가 실제로 뚫는 순서 그대로 byteforce 화이트해커가 먼저 뚫어 보고, 막는 법까지 드립니다.
더 깊은 곳 — 서버측 · 세션 · 인프라
빠르게 만들수록 공격당할 수 있는 지점도 늘어납니다. 눈에 보이는 입력 검증 말고도, 서버가 대신 요청을 보내는 부분, 세션과 토큰, 교차 출처 정책처럼 잘 드러나지 않는 곳을 공격자가 거치는 순서대로 점검합니다.
- SSRF · 서버측 요청 위조서버가 대신 요청을 보내도록 속여서 내부망·클라우드 메타데이터·시크릿을 빼내는 공격입니다.
- RCE · 원격 코드 실행역직렬화·템플릿 주입·파일 업로드를 통해 공격자가 서버에서 자기 코드를 실행하는 단계입니다.
- 접근통제 우회 · IDOR요청에 들어가는 ID만 바꿔서 남의 데이터를 읽거나 고치는 공격입니다. Broken Access Control이라고 부릅니다.
- 세션 탈취 · JWT 취약점세션 고정·토큰 위조·약한 서명을 이용해 남의 로그인 상태를 그대로 가져다 쓰는 인증 우회입니다.
- 잘못된 CORS · 보안 헤더 누락교차 출처 정책이 느슨하거나 보안 헤더가 빠지면 브라우저가 걸어 주는 기본 방어가 풀립니다.
분류 명칭은 공개 표준인 OWASP Top 10 · CWE · OWASP ASVS를 따릅니다. 어디를 볼지 정하는 기준일 뿐이고, 실제로 뚫리는지는 화이트해커가 직접 확인합니다.
스캐너를 돌려 주는 곳은 많습니다.
사람이 직접 공격해 확인하는 곳은 드뭅니다.
byteforce는 도구로 의심되는 곳을 모은 뒤, 보안 전문가가 그 자리를 직접 공격해 봅니다. 자동 스캔에서 멈추지 않습니다.
무엇이 다른가
보안을 확보하는 방법은 크게 세 가지입니다. 스캐너를 직접 돌리거나(DIY), 일반 점검 업체에 맡기거나(전통), byteforce처럼 사람이 직접 공격해 보고 배포마다 다시 보거나. 같은 항목에서 셋이 어떻게 다른지 정리했습니다.
| 항목 | byteforce | 자동 스캐너 도구DIY · SAST · DAST | 일반 보안 점검 업체전통 점검 |
|---|---|---|---|
| 검증 방식 | 사람이 직접 공격해 보며 확인 | 자동 패턴 매칭만 | 체크리스트 점검 위주 |
| 오탐·미탐 | 스캐너 결과를 사람이 걸러 실제 취약점만 추림 | 오탐 많고, 맥락 취약점은 놓침 | 정해진 범위 밖은 못 잡음 |
| 지속성 | 배포할 때마다 다시 점검(WATCH 구독) | 돌릴 때 1회 | 계약 단위 1회 점검 |
| 재점검 | 수정 후 같은 항목 다시 확인·횟수 제한 없음 | 다시 돌려도 수정 여부는 확인 안 됨 | 보통 추가 비용 |
| 바이브코딩 특화 | AI 생성 코드에서 자주 터지는 곳을 앎 | 도구 무관·범용 규칙 | 일반 웹 점검 기준 |
| 조치 동행 | 재현 PoC·구체 조치안 제공, 막힐 때까지 함께 | 결과 목록만 출력 | 보고서 전달 후 종료 |
보안 전문가가 직접 검증하고, 배포마다 다시 보고, 고칠 때까지 함께합니다. 이 세 가지를 한 곳에서 합니다.
어떻게 점검하나
- 스코핑무엇을 어디까지 볼지, 어떤 접근 권한이 필요한지 먼저 정합니다.
- 정적·동적 스캔코드와 실제로 돌아가는 서비스를 도구로 훑어서 의심되는 곳을 모읍니다.
- 수동 검증스캐너가 표시한 곳을 사람이 직접 공격해 봅니다. 자동 스캔만으로 끝내지 않습니다.
- 리포트그대로 재현되는 PoC와 구체적인 조치 방법을 적어서 전달합니다.
- 재점검수정한 뒤 같은 항목을 다시 공격해 보고 실제로 막혔는지 확인합니다.
자동 스캔으로 의심되는 곳을 모으고, 진짜 뚫리는지는 보안 전문가가 직접 공격해 확인합니다.
가격 · 요율표
한 번 점검부터 계속 지켜보기까지, 세 가지로 제공합니다.
1회로 끝나는 진단과 배포마다 다시 보는 구독, 필요한 쪽을 고르시면 됩니다.
| 단계 | 설명 | 주기 | 가격 |
|---|---|---|---|
| LITE | 빠른 취약점 스캔 | 1회 | ₩290만 |
| FULL | 코드·인프라 정밀 진단 | 1회 | ₩690만 |
| WATCH | 지속 모니터링·재점검 | 월 구독 | ₩99만 · 월 |
표시 가격은 부가세 별도입니다. 실제 범위·규모에 따라 조정될 수 있으며, 제안서에서 확정합니다. WATCH 월 구독은 언제든 해지할 수 있습니다.
WATCH는 배포할 때마다 다시 점검합니다.
- 배포마다코드가 바뀔 때마다 같은 기준으로 다시 봅니다. 새로 생긴 취약점을 다음 배포 전에 찾아냅니다.
- 재점검 무제한고치면 같은 항목을 다시 검증합니다. 횟수에 제한을 두지 않고, 실제로 막혔는지까지 확인합니다.
- 노출 시간 단축취약점이 열려 있는 동안이 가장 위험합니다. 계속 지켜보면 그 시간을 줄일 수 있습니다.
WATCH · 거버넌스 루프
보안은 한 번 보고 끝나지 않고, 계속 돌아가는 과정입니다.
빠르게 만든 코드는 배포할 때마다 다시 봐야 합니다. byteforce는 그 반복을 정책 · 통제 · 감사 세 단계로 운영합니다. 무엇을 어디까지 볼지 정하고, 배포 과정에 점검을 끼워 넣고, 무엇을 봤고 무엇을 막았는지 기록으로 남깁니다. WATCH는 이 과정을 매월 반복하는 월 구독으로 만든 것입니다.
- 정책무엇을 어디까지 볼지 범위와 기준을 정합니다.
- 통제배포할 때마다 같은 점검을 흐름에 넣습니다.
- 감사무엇을 봤고 무엇을 막았는지 남겨 다시 봅니다.
SELF-AUDIT · 자가 점검 기록
우리 사이트도 같은 기준으로 점검합니다.
| 일자 | 점검 항목 | 결과 |
|---|---|---|
| 2026.08.08 | AUD-01HTTP 접속 시 HTTPS 강제 전환 | 강제308 → HTTPS |
| 2026.08.08 | AUD-02전송 구간 보안(HSTS) 적용 | 적용max-age 2년 |
| 2026.08.08 | AUD-03관리자 콘솔 무인증 접근 차단 | 차단401 |
| 2026.08.08 | AUD-04관리자 API 무인증 접근 차단 | 차단401 |
| 2026.08.08 | AUD-05공개 응답·자산에 노출된 시크릿 | 0건자산 10개 점검 |
| 2026.08.08 | AUD-06공개 API 응답의 개인정보 항목 | 0건handle 조회 |
| 2026.08.08 | AUD-07보안 응답 헤더(형식 위장·프레이밍·주소 유출) | 적용형식 위장 차단 · 외부 프레이밍 차단 · 주소 유출 절제 |
대상 byteforce.ai.kr · 배포 직전에 다시 실행합니다. 기계로 확인할 수 없는 점검은 이 표에 싣지 않습니다.
자주 묻는 것
먼저 궁금해하시는 것들
스캐너만 돌리는 것과 무엇이 다른가요?
도구로 의심되는 곳을 모으는 것까지는 같습니다. 다른 점은 그다음입니다. 스캐너가 표시한 곳을 보안 전문가가 직접 공격해 보고, 오탐을 걷어낸 뒤 실제로 뚫리는 것만 남깁니다. 자동 스캔에서 멈추지 않습니다.
바이브코딩으로 만든 서비스도 봐 주나요?
보안센터는 바로 그런 코드를 위한 구성입니다. AI가 빠르게 만든 코드에서 자주 터지는 곳, 그러니까 하드코딩 시크릿, RLS 누락, 인증·인가 누락 같은 것부터 봅니다. 어떤 스택을 쓰는지, 어디가 불안한지 한 줄만 주시면 됩니다.
한 번 점검하면 끝인가요?
LITE와 FULL은 1회 진단입니다. 코드는 배포할 때마다 바뀌고, 그때마다 새 취약점이 생길 수 있습니다. 그래서 WATCH 월 구독은 배포할 때마다 같은 기준으로 다시 보고, 수정한 항목을 횟수 제한 없이 재점검합니다.
취약점을 찾으면 고치는 것도 도와주나요?
그대로 재현되는 PoC와 구체적인 조치 방법을 적어서 전달합니다. 결과 목록만 넘기고 끝내지 않습니다. 수정한 뒤에는 같은 항목을 다시 공격해 보고 실제로 막혔는지 확인합니다.
어떤 기준으로 무엇을 점검하나요?
공개된 보안 표준을 점검 항목의 기준으로 씁니다. OWASP Top 10, CWE, OWASP ASVS 같은 분류입니다. 인젝션(SQLi·XSS), 접근통제 우회(IDOR), 서버측 요청 위조(SSRF), 원격 코드 실행(RCE), 세션·인증 우회, 시크릿 노출, 잘못된 CORS·보안 헤더 누락 같은 항목을 따라 봅니다. 표준 명칭은 볼 곳을 정해줄 뿐, 뚫리는지 여부는 화이트해커가 직접 공격해 확인합니다.
어떤 사람들이 보나요?
현직 화이트해커와 보안 전문가로 이뤄진 네 개의 팀입니다. 넥슨 출신, DEF CON(라스베이거스에서 열리는 세계 최대 해킹 컨퍼런스) 경력, 현직 보안업체 전문가, 이렇게 세 갈래의 배경을 가진 사람들이 침투 테스트·코드 점검·위협 모델링 관점으로 코드를 봅니다. 도구가 표시한 곳을 공격자 입장에서 직접 다시 공격해 봅니다.
먼저 무엇부터 하면 되나요?
지금 쓰는 코드에서 불안한 곳부터 봐 드립니다. 계약 의무 없이 한 줄 문의로 시작하고, 점검 범위와 권한은 함께 정합니다. 바로 연락이 편하시면 contact@byteforce.ai.kr로 주셔도 됩니다.
보안점검 제안서를 보내드립니다
점검 대상과 스택을 알려주시면, 범위와 일정을 담은 제안서를 영업일 기준으로 회신드립니다. 보안 전문가가 직접 검토합니다.
- 대상
- 담당자·회사를 적으면 채워집니다.
- 점검 대상
- 오른쪽에 적으신 범위가 그대로 담깁니다.
- 예상 점검 지점
- 침투 테스트SQLi · SSRF · RCE · IDOR
- 코드 점검하드코딩 시크릿 · 취약 의존성
스택을 적으면 이 조합에서 먼저 볼 지점이 표시됩니다.
쉽게 말해: 이 조합에서 보통 먼저 살펴보는 곳입니다. 실제 진단 결과는 점검을 마친 뒤 제안서에 담깁니다.
- 점검 기준
- OWASP Top 10 · ASVS
- 우선순위
- 일반
여기 잡히지 않은 부분도 범위는 회신에서 함께 정합니다.
표준 · 근거
OWASP 같은 공개 표준을 기준으로 점검합니다.
코드·인프라 위협은 OWASP Top 10 · CWE · OWASP ASVS를 기준으로 봅니다. 같은 서비스가 LLM을 쓰고 있으면, 아래 항목은 AI 애플리케이션 전용 분류인 OWASP Top 10 for LLM Applications에도 대응됩니다. 표준은 출발점일 뿐입니다 — 실제로 뚫리는지는 보안 전문가가 직접 확인합니다.
- 하드코딩 시크릿LLM02 민감정보 노출
- 인젝션LLM05 부적절한 출력 처리
- 취약한 의존성LLM03 공급망
코드가 AI를 호출하지 않는 일반 위협(RLS 누락 · 인증·인가 누락 · SSRF · IDOR · 세션 우회 · CORS)은 OWASP Top 10 · CWE · ASVS로 봅니다. LLM 전용 분류에 억지로 끼우지 않습니다.