Skip to main content

One post tagged with "python"

View All Tags

오픈 소스 라이브러리 s2n 회고

· 7 min read
te
te
Sofrware Engineer

title

KT Cloud TECHUP 사이버 보안 과정의 첫 팀 프로젝트로 오픈 소스 파이썬 라이브러리를 개발했습니다.

프로젝트 개요​

결과 링크:

팀 구성:

  • 5인으로 이루어진 팀이며, 제가 리드 역할을 맡았습니다.
  • 2명의 컴퓨터 관련 전공자와 저를 포함한 3명의 비전공자로 구성됐습니다.
    • 비전공자 팀원 두 분에겐 첫 개발 프로젝트였습니다.

프로젝트 기간:

  • 총 5주
  • Sprint 1 : 2025/11/03 ~ 2025/11/16
  • Sprint 2 : 2025/11/17 ~ 2025/12/01

역할

각 팀원의 관심사와 목표에 따라 스프린트 별로 내부 팀을 나누었습니다.

  • Sprint 1: 인프라팀 / 코어팀
  • Sprint 2: 라이브러리팀 / 클라우드팀

저는 인프라-라이브러리 팀에 속하였으나,
팀 리드로서 팀 서포트 및 여러 일을 맡았습니다.

s2n 취약점 스캐너 라이브러리​

소개​

s2n-cli

s2n은 파이썬 오픈소스 취약점 스캐너입니다.

  • PyPi에 등록 및 배포가 되어있어, 파이썬 환경에서 패키지를 다운받아 실행할 수 있습니다.
  • CLI 기능을 제공하여 파이썬과 여러 환경에서 실행 가능합니다.
    • Docker 이미지 또한 배포되어 있어, 컨테이너 환경에서도 실행할 수 있습니다.
  • XSS, CSRF, SQL Injection 등 7종의 주요 공격 기법 취약성을 스캔할 수 있습니다.
  • 타겟 URL을 입력하여 취약점을 스캔합니다.
    • DAST 방식으로 런타임 취약점을 점검합니다.
  • 스캔 대상에 실질적인 피해를 주지 않는 안전한 방식을 고려했습니다.
  • 스캔 결과를 JSON, HTML로 Export하거나 콘솔을 출력할 수 있습니다.

기여​

s2n을 개발하면서 제가 기여한 부분은 다음과 같습니다:

  • 시스템 설계 및 주요 인터페이스 개발
  • CSRF 플러그인 개발 및 플러그인 전반 코드 컨벤션 적용하여 리팩터링
  • 스캔 엔진 인증 모듈, CLI 인터페이스 개선 및 유지보수
  • 플러그인 전반의 Pytest 작성 및 conftest로 공용 모킹 모듈 작성
  • 배포 파이프라인에 테스트 적용 및 유지보수
  • CI/CD 배포 파이프라인 개발 및 유지보수
  • Docker Image 개발 및 자동 배포 환경 구축
    • dev : Github Container Registry 배포 (s2n:dev)
    • main : Docker Hub 퍼블릭 레지스트리 배포 (opens2n/s2n-docker:latest)

작업 PR​

시스템 설계 및 동작 원리​

s2n-system

위 설계도는 s2n의 전체 구조를 한눈에 보여주는 시스템 아키텍처입니다.

  1. 사용자가 CLI 혹은 코드 레벨에서 Scanner 객체를 호출하여 인자를 입력하고
  2. 스캐너가 입력을 받아 플러그인을 통해 분석을 수행한 뒤
  3. 리포트를 출력하기까지의 흐름을 중심으로 구성했습니다.
  • 코드 레벨과 CI/CD 환경에서 실행될 수 있도록 CLI 인터페이스까지 설계 단계에서 고려했습니다.
  • 동적 분석(DAST)을 기반으로, 실행 흐름에서 생성되는 request 인스턴스를 공용 모듈이 중앙에서 관리하도록 설계했습니다. 이를 통해 세션과 인증을 일관되게 처리할 수 있도록 구조를 정리했습니다.

가장 바깥에는 사용자가 진입하는 Entry Point가 있습니다. CLI에서 URL과 설정, 플러그인을 직접 지정하거나, Python 패키지로 Scanner 클래스를 불러와 사용할 수 있습니다.

입력된 요청은 Core System을 통해 처리됩니다. 코어 영역은 스캐너의 핵심 로직이 모여 있는 부분으로, 설정 관리, 인증 처리, 로깅, HTTP 요청 관리, 크롤링, 세션 유지 등
실제 스캐닝 과정에 필요한 공통 기능이 모두 이 계층에 포함됩니다. 스캔 과정 중 발생하는 집계, 에러, 인증, 세션 관리 등의 처리가 이 코어 시스템을 통해 조율됩니다.

실제 취약점 탐지는 Plugin System에서 이루어집니다.

플러그인 매니저가 필요한 플러그인을 로드하고 실행 파이프라인을 구성하면, SQL Injection, XSS, CSRF 등을 포함한 다양한 플러그인이 타겟 URL에 대해 검사를 수행합니다. 설계 초기부터 확장 가능한 구조를 염두하여,새로운 플러그인을 추가하는 것이 가능하게끔 개발했습니다.

스캔 과정에서 발생할 수 있는 오류들은 Error Handling 시스템에서 통합적으로 다룹니다. 네트워크 오류, 인증 문제, 플러그인 실행 오류 등을 분류하고 적절히 대응하여 스캐너 전체가 중단되지 않고 동작하도록 했습니다.

최종적으로 결과는 Reporting System에서 다양한 형식으로 출력됩니다. JSON, HTML, 콘솔 출력, CSV 등 사용 목적에 맞추어 결과를 가공하며, 특히 HTML 리포트는 대시보드 형태로 시각적 확인이 가능합니다.

팀 협업​

sprint-teams

팀원 과반이 프로젝트 경험이 부족하였기에, 자연스럽게 리드를 맡게 되었습니다.
사실 어떤 직함이나 역할을 갖고 리드 역할을 한 것은 처음이었기에, 꽤 도전적인 경험이었습니다.
(프로젝트를 진행하면서, 전직장에서 FE 챕터 리드님이 고생하시던 모습이 자주 떠올랐습니다.)

팀을 리드하면서 스스로 지키자고 세웠던 원칙은 다음과 같습니다:

  • 경험이 더 있다고 팀원들에게 오만하게 굴지 말것
  • 과정과 결과를 기록할 것
  • 누구든 자유롭게 의견을 낼 수 있도록 할 것
  • 나를 포함한 한 사람의 의견에 프로젝트가 좌우되게 하지 않을 것
  • 팀 전원이 하고 싶은 일을 하도록 조율할 것
  • 모르는 부분이 있으면 누구나 질문하고, 성실히 답할 것
  • 즐거운 분위기를 유지할 것

혼자서 오랫동안 취업 준비를 해서 그런지, 다양한 배경의 팀원들과 함께하여 무척 즐거웠습니다.
이번 프로젝트를 통해 개발을 처음 시작할 때의 열정이 떠올라 보람찼습니다.

노션 기록과 문서화​

s2n-notion

현직에 있을 때도 결과와 과정의 문서화를 중시하던 편이라,
팀원 모두에게 문서 기반으로 작업하도록 요청하였습니다.

Github PR​

pr-s2n

오픈 소스를 만드는 프로젝트이기에, Git과 Github 활용이 중요했습니다. 이번 기회에 깃 관련 경험이 적은 팀원들 위해 매뉴얼 작성과 간단한 세션을 진행했습니다.
결과적으로, 팀원 전원이 PR을 1회 이상 작성하였고, 브랜치를 병합했습니다.

바쁘게 작업을 하다보면 일일히 회고를 작성하기 어렵습니다.
PR 단위로 작업을 한 뒤, 문서를 작성하여 작업 이력을 활용할 수 있습니다.
팀 규칙으로 PR 작성을 ruleset으로 정하였고, PR 템플릿을 작성했습니다.

s2n-git-1 s2n-git-2

프로젝트 초기에 브랜치 전략을 실제 업무 현장처럼 다소 복잡하게 구성했는데,
추후 4시간동안 꼬인 커밋을 리베이스로 정리하면서 후회도 했습니다.
하지만 고생한만큼 반복하여 발생하던 깃 충돌 문제를 해결할 수 있었습니다.
이후 깃 브랜치 전략을 main - dev - 작업 브랜치 3단계로 단순화하였습니다.

트러블 슈팅 및 기술적 도전​

Github s2n PR 리스트

작업의 모든 과정을 PR로 기록했습니다.
pull_request_template.md를 작성하여 팀원 전원이 자신이 올린 PR을 설명하도록 팀 규칙을 정했습니다. 개발 과정에서 기억에 남고 학습이 되었던 PR 내용을 간략히 설명하면 다음과 같습니다.

일관된 개발 환경 구축​

파이썬 경험도 많지 않고, 도커 또한 경험이 많지 않았기에 서툴렀던 점이 많았습니다.
스스로 학습도 해가며, 팀원들에게 도움이 되도록 PR문서에 매뉴얼도 함께 작성했습니다.

  1. Python 버전 및 .venv 통합 (PR #43) 팀원별 Python 버전이 달라 실행 오류가 발생하던 문제를 해결하기 위해 Python 3.11.14 + 통일된 가상환경(.venv) 기반의 개발 환경을 표준화했습니다.
  • 모든 팀원이 pyenv로 동일한 버전을 설치하도록 매뉴얼화
  • setup_venv 스크립트를 통해 한 번에 .venv 생성 및 활성화
  • 코드 에디터(vscode, PyCharm 등)의 프로젝트 전역 Python 경로를 .envs/python/.venv로 통합
  • .gitignore를 정리하고 불필요한 항목 제거, 환경 관련 폴더만 정확히 제외하도록 구조 개선
  • 추가로 학습 내용에 대해 글 작성 뒤 팀원들에게 공유 : venv 학습 문서

팀 리드로서 프로젝트 초반에 신경써야할 부분이었지만, 뒤늦게라도 작업하여 반복된 (주로 린트) 문제를 해결할 수 있었습니다.

  1. 로컬 DVWA 환경 구축 (PR #4) 보안 스캐너를 테스트하기 위한 DVWA(Local Damn Vulnerable Web App) 환경을 직접 구성했습니다. Docker 기반으로 누구나 동일한 환경에서 취약점 스캔 실험을 할 수 있도록 설계했습니다.
  • .envs/dev 경로에 DVWA용 docker-compose.yml, Dockerfile 작성
  • 실행/중지를 위한 스크립트(run_dvwa.sh, stop_dvwa.sh)를 개발
  • .env.dev 파일을 이용해 팀원 간 환경 변수를 통일
  • 팀원들은 bash run_dvwa.sh 한 번으로 DVWA를 실행하고, 동일 주소에서 테스트 가능

이 작업을 통해 팀 전체가 동일한 취약점 테스트 환경을 공유할 수 있게 되었습니다.

Docker Image 멀티 플랫폼​

title 이미지 배포 이후, Vagrant로 linux debian을 실행하였는데, 다음과 같은 에러가 났습니다.

PR-93 링크

에러 원인을 확인해보니, 컨테이너 이미지를 단일 아키텍처(ARM)에서만 제공할 경우, AMD에서 실행할 수 없다는 문제가 있었습니다. 이를 해결하기 위해서 배포 스크립트의 docker 이미지 빌드 단계를 수정했습니다. (자세한 내용은 위의 PR 링크에 기록했습니다.) docker buildx를 활용하여 멀티 플랫폼 이미지를 자동으로 빌드하도록 CI/CD 파이프라인을 개선하는 작업이었습니다.

기여한 내용은 다음과 같습니다:

  • GitHub Actions 워크플로우에 setup-buildx-action을 추가하여 멀티 아키텍처 빌드 환경 구성
  • linux/amd64, linux/arm64 대상 이미지 빌드 및 Docker Hub로 자동 푸시 설정
  • Dockerfile을 멀티 스테이지로 개선하여 이미지 크기 최적화
  • 이미지 실행 시 Python 의존성이 정상적으로 동작하도록 런타임 환경 검증

이 과정을 통해 팀원들 모두 M1/M2 환경에서도 문제 없이 s2n을 실행할 수 있게 되었고, 프로젝트의 배포 범위와 활용성을 크게 늘린 의미 있는 작업이었습니다.

신경쓰지 못한 부분이었는데, 실제 사용을 해보면서 알 수 있어 좋았습니다.

Pytest​

PR-83 링크

프로젝트가 커질수록 수동 테스트만으로는 기능 안정성을 보장하기 어려웠습니다. 이에 pytest 기반의 자동 테스트 환경을 구축하여 플러그인 동작과 핵심 스캐너 로직을 검증할 수 있도록 했습니다. 이 과정에서 코드 전반에 일정한 패턴을 적용하도록 리팩터링을 함께 진행했습니다.

주요 작업 내용은 다음과 같습니다:

  • 프로젝트 구조에 맞춰 tests/ 디렉토리 구성 및 기본 테스트 스켈레톤 작성
  • 스캐너 핵심 엔진, 유틸리티 함수, 플러그인 로딩 로직 테스트 케이스 구현
  • Mocking을 활용해 HTTP 요청/응답을 가짜 객체로 처리하여 안전하게 테스트하도록 구성
  • CLI 실행 결과를 캡처하여 정상적으로 출력되는지 검증하는 테스트 추가
  • GitHub Actions에서 pytest가 자동 실행되도록 CI 통합

긴 글 읽어주셔서 감사합니다!