보안 사고방식 기르기

지난 글에서 공격 표면의 개념과 축소 전략을 다뤘다. 공격 표면을 줄이는 것은 기술이 아니라 습관이다. 그 습관의 뿌리가 **보안 사고방식(Security Mindset)**이다. 보안 사고방식은 특별한 기술이 아니라, 코드를 작성할 때 “이 코드가 어떻게 악용될 수 있는가?”를 자연스럽게 묻는 태도다.

보안 사고방식 vs 기능 사고방식

개발자의 기본 사고방식은 기능 중심이다. “이 기능이 정상적으로 동작하는가?”가 핵심 질문이다. 보안 사고방식은 여기에 하나를 더한다. “이 기능이 어떻게 악용될 수 있는가?”

두 사고방식은 상충하지 않는다. 보안 사고방식을 갖춘 개발자는 기능을 더 빠르게 만들지는 않지만, 나중에 고쳐야 할 취약점을 훨씬 적게 만든다. 장기적으로 팀의 속도가 빨라진다.

7가지 핵심 원칙

1. 공격자 시각으로 생각하라

코드를 작성하기 전에 자신이 공격자라면 어떻게 이 기능을 악용할지 생각한다. 폼을 만든다면 “비어있는 값은? 엄청나게 긴 값은? 특수문자는? 음수는? 다른 사용자 ID를?”을 묻는다.

2. 실패를 안전하게 설계하라(Fail Secure)

인증 검사 코드에 버그가 생겼을 때 시스템이 어떻게 되는가? 버그로 인해 인증을 통과시킨다면 Fail Open이다. 차단한다면 Fail Secure다. 항상 Fail Secure를 선택한다.

# Fail Open (위험)
def is_admin(user):
    try:
        return db.get_role(user) == "admin"
    except Exception:
        return True  # 오류 시 관리자로 처리 — 절대 금지

# Fail Secure (안전)
def is_admin_safe(user):
    try:
        return db.get_role(user) == "admin"
    except Exception:
        return False  # 오류 시 거부 — 올바른 기본값

3. 신뢰는 검증 후에만(Zero Trust)

같은 서버의 다른 프로세스, 내부 API, 프런트엔드에서 오는 값도 모두 검증한다. 공격자가 내부 네트워크에 이미 침입해 있을 수 있다. “내부에서 왔으니 안전하다”는 가정은 위험하다.

4. 심층 방어(Defense in Depth)

하나의 방어 계층에 모든 것을 의존하지 않는다. 입력 검증이 실패해도 DB 파라미터화 쿼리가 SQL 인젝션을 막는다. 그것도 실패하면 DB 권한 분리가 피해를 제한한다.

5. Shift Left — 보안을 초기에

비용 비교:
  설계 단계 취약점 발견:   $80
  개발 단계 취약점 발견:   $240
  테스트 단계 취약점 발견: $960
  배포 후 취약점 발견:     $7,600 (NIST 연구 기준 상대 비율)

코드 리뷰, PR 체크리스트, 정적 분석(SAST), 의존성 스캔을 CI/CD에 통합한다.

6. 단순할수록 안전하다(KISS)

복잡한 코드는 취약점이 숨기 좋다. 인증 로직이 200줄이라면 검토하기 어렵고 버그가 숨어있을 가능성이 높다. 보안 관련 코드일수록 단순하고 읽기 쉽게 작성한다. 검증된 라이브러리를 쓰고, 직접 암호화 구현을 하지 않는다.

7. Assume Breach — 침해를 가정하라

“우리 시스템은 뚫리지 않는다”는 가정 대신 “이미 침해됐다면 어떤 피해가 발생하는가?”를 묻는다. 이 질문이 최소 노출, 데이터 분리, 감지 및 대응 계획을 만들게 한다.

실천 방법: 보안 체크리스트

보안 사고방식을 코드 리뷰에 바로 적용할 수 있는 체크리스트다.

# PR 보안 체크리스트

## 입력
- [ ] 모든 외부 입력은 검증/타입 강제가 이뤄지는가?
- [ ] SQL 쿼리는 파라미터화되어 있는가?
- [ ] 파일 경로를 사용자 입력으로 구성하지 않는가?

## 인증 · 인가
- [ ] 새 엔드포인트에 인증 미들웨어가 적용됐는가?
- [ ] 사용자가 자신의 자원만 접근할 수 있는가?
- [ ] 에러 메시지가 민감 정보를 노출하지 않는가?

## 데이터
- [ ] 민감 데이터가 로그에 기록되지 않는가?
- [ ] 새 시크릿은 환경변수/시크릿 관리 도구를 쓰는가?

## 의존성
- [ ] 새 패키지는 활발히 유지 관리되는가?
- [ ] CVE 취약점 여부를 확인했는가?

보안 문화 만들기

개인의 사고방식도 중요하지만, 팀 문화가 더 큰 영향을 미친다. 팀에서 다음을 정례화하면 보안 사고방식이 조직에 녹아든다.

보안 챔피언 제도: 각 팀에 보안 담당자를 지정한다. 풀타임 보안 전문가가 아니어도 된다. 보안 리뷰를 주도하고 팀 내 보안 질문의 첫 번째 창구가 된다.

Blameless Postmortem: 보안 사고 발생 시 개인을 탓하지 않고 시스템의 결함을 찾는다. 이렇게 해야 다음에 문제를 빠르게 보고하는 문화가 생긴다.

정기 위협 모델링: 스프린트마다 새 기능에 대해 간략한 위협 모델링을 10분만 수행해도 많은 취약점을 사전에 발견한다.

보안 사고방식은 하루아침에 생기지 않는다. 하지만 PR마다 보안 체크리스트를 적용하고, 코드 리뷰에서 보안 질문을 한 번씩 더 던지는 것만으로 6개월 후에는 팀 전체의 보안 역량이 눈에 띄게 향상된다.

---

지난 글: 공격 표면 이해하기

다음 글: 주요 웹 공격 유형 한눈에 보기

읽어주셔서 감사합니다. 😊