A Framework for Integrating Application Security into Software Engineering (FIASSE) using the Securable Software Engineering Model (SSEM)
# 소프트웨어 엔지니어링에 애플리케이션 보안을 통합하기 위한 프레임워크 (FIASSE)
[](https://creativecommons.org/licenses/by-sa/4.0/)
**참고:** 이 저장소는 진행 중인 작업입니다. 기여를 환영합니다!
## 개요
TL;DR: [문서](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md)를 읽어 주세요. [FIASSE 웹사이트](https://fiasse.org)를 살펴보세요. 기여하려면 [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions)를 방문하세요.
이 저장소에는 소프트웨어 엔지니어링에 애플리케이션 보안을 통합하기 위한 OWASP 프레임워크(FIASSE)의 리소스와 자료가 포함되어 있습니다. FIASSE('phase'처럼 /feiz/로 발음)는 **보안 가능한(securable)** 소프트웨어를 구축하기 위한 **개발자 중심의 원칙 기반 접근 방식**을 장려하는 벤더 독립적 프레임워크입니다. 이는 보안이 개발과 마찬가지로 역동적이고 지속적인 과정임을 인식합니다. 또한 코드 자체를 형성하는 원칙에 보안을 내장함으로써 확립된 소프트웨어 엔지니어링 용어를 사용하여 보안을 소프트웨어 아키텍처, 설계 및 엔지니어링에 통합하는 **공통 설계 언어**로서 보안 가능한 소프트웨어 엔지니어링 모델(SSEM)을 도입합니다. 이 프레임워크는 개발 팀이 코드의 수명 주기 전반에 걸쳐 사이버 사건으로 인한 중대한 영향의 가능성을 줄이면서 탄력적으로 컴퓨팅 가치를 추가할 수 있도록 합니다.
FIASSE는 창조적(creational) 프레임워크입니다. 이는 소프트웨어에서 보안이 어떻게 구현되는지를 다루며, 엔지니어링 결정을 보안 가능한 결과에 직접 연결합니다. 이는 보증(assurance) 프레임워크, 성숙도 모델, 또는 통제 카탈로그나 취약점 지표를 대체하는 것이 아닙니다. 이러한 접근 방식을 보완하고 보증 및 규정 준수에 대한 다운스트림 압력을 완화합니다.
## 목적
개발자가 깊은 보안 전문 지식 없이도 보안 가능한 소프트웨어를 만들 수 있도록 **역량을 부여**하는 실용적인 지침을 제공하고, 보안 전문가가 자신의 보안 경험을 소프트웨어 엔지니어링에 효과적으로 통합하도록 안내하는 것입니다. FIASSE는 **소프트웨어 엔지니어링 관점**을 통해 이를 달성하며, 인지 부하를 줄이고 개발 팀과 보안 팀 간의 협업을 촉진합니다.
## 무엇이 다른가?
OWASP Top 10과 같은 보증 중심 프로젝트가 피해야 할 것(차단 목록)을 강조하는 반면, OWASP FIASSE는 따라야 할 긍정적인 속성과 관행의 집합(허용 목록)을 제공합니다. 이 접근 방식은 개발자가 익스플로잇 기법을 배우거나 취약점 중심의 사고방식을 채택하도록 요구하는 대신, 기존 소프트웨어 엔지니어링 기술을 활용하여 보안 가능한 소프트웨어를 구축합니다. 핵심은 익숙한 엔지니어링 원칙을 통해 실용적이고 안전한 코딩을 가능하게 하는 데 있습니다.
개발 프로세스 내에서 보안의 실질적인 역할을 명확히 정의함으로써, 이 프레임워크는 비즈니스 가치가 효과적으로 포착되도록 보장합니다. 코드가 작성되기 전에 명시적인 보안 기대치를 설정하면 보안 결함이 나중에 발견되어 수정해야 할 가능성이 줄어듭니다. 효과적인 도입은 기존 보증 지표를 개선하고, 발견 사항의 변동(churn)을 줄이며, 더 지속 가능한 수정을 만들어내고, 수정 시간을 단축해야 합니다.
## 핵심 가치
FIASSE는 네 가지 핵심 가치에 의해 방향이 정해집니다. 각 가치는 상대적 선호를 표현합니다. 양쪽 모두 가치가 있지만, 선택을 해야 할 때 FIASSE는 왼쪽을 선호합니다.
- **보안 통제보다 보안 가능한 속성**: 약점을 보완하기 위해 사후에 추가된 보안 통제보다 시스템을 구축하고 방어 가능하게 유지할 수 있게 하는 엔지니어링 품질을 선호합니다.
- **평가보다 참여**: 작업이 완료된 후 수행되는 평가보다 수명 주기 전반에 걸친 보안과 개발 간의 구조화된 참여를 선호합니다.
- **보안 전문 용어보다 엔지니어링 제1원칙**: 보안 특유의 전문 용어나 적대적 휴리스틱보다 확립된 소프트웨어 엔지니어링 제1원칙에 기반을 두는 것을 선호합니다.
- **보안 활동보다 비즈니스 가치**: 그 자체를 목적으로 추구되는 보안보다 조직의 가치 창출을 지속시키는 보안을 선호합니다.
## 핵심 원칙
- **보안 가능성 패러다임**: "안전함"이라는 정적인 상태는 존재하지 않습니다. 오늘 안전하다고 선언된 시스템도 내일은 취약해질 수 있습니다. FIASSE는 엔지니어링 목표를 "안전한가?"에서 "보안이 유지될 수 있도록 구축되었는가?"로 전환하며, 이를 적응형 복원력, 진화적 보안, 지속적 개선을 통해 달성합니다.
- **복원력 있게 컴퓨팅 가치 제공**: 비즈니스 맥락에서 소프트웨어 엔지니어링의 최우선 지침입니다. 소프트웨어는 기능적 요구사항을 충족하는 동시에, 각 변경 이후에 따르는 변화, 스트레스, 공격을 견딜 수 있게 하는 보안 가능한 품질을 유지해야 합니다.
- **보안 미션: 실질적 영향 감소**: 보안의 미션은 사이버 사건의 실질적 영향 가능성을 줄이는 것입니다. 침해의 완전한 제거는 실용적인 비즈니스 목표가 아니므로, 보안 전략은 비즈니스 목표 및 위험 허용 범위와 일치해야 합니다.
- **품질-보안 관계**: 보안은 소프트웨어 품질을 초과할 수 없습니다. 소프트웨어를 이해하고, 변경하고, 테스트하고, 관찰하기 쉽게 만드는 품질은 곧 보안을 가능하게 하는 동일한 품질입니다. 엔지니어링 품질에 대한 투자는 보안 투자입니다.
- **개발자 중심 보안**: 소프트웨어 엔지니어가 침투 테스터의 사고방식을 받아들이도록 요구하는 대신, 익숙한 소프트웨어 엔지니어링 원칙을 사용하여 보안 가능한 시스템을 구축할 수 있도록 역량을 부여합니다.
- **공통 설계 언어로서의 SSEM**: 확립된 소프트웨어 엔지니어링 용어(예: 분석 가능성, 수정 가능성, 테스트 가능성)를 활용하여 보안 속성을 정의하고 논의합니다. 이를 통해 개발자가 보안에 접근하기 쉬워지고, 보안 전문가에게는 평가를 위한 공통 기반이 제공됩니다.
- **보안을 개발 및 비즈니스 목표와 정렬**: 보안과 개발은 대립 관계가 아니라 상호 보완 관계입니다. AppSec은 SDLC 초기에, 특히 요구사항 수집 및 기능 계획 단계에서 참여하여 코드가 작성되기 전에 기대사항이 명확해지도록 합니다.
- **투명성 원칙**: 권한이 부여된 주체가 내부 상태와 동작을 이해할 수 있도록 시스템을 설계합니다. 구조화된 로깅, 계측, 감사 추적은 외부 도구만으로 제공되는 것이 아니라 코드에 내장됩니다.
- **최소 놀람의 원칙**: 시스템은 사용자, 개발자, 관리자에게 직관적이고 예측 가능한 방식으로 동작합니다. 예측 가능성은 분석을 돕고 인지 부담을 줄이며 신뢰 경계를 명확하게 합니다.
- **AppSec에서 일급 시민으로서의 요구사항**: 보안 기능, 위협 시나리오, 보안 인수 기준은 요구사항 프로세스를 통해 전달됩니다. 취약점은 흔히 한 번도 명시된 적 없는 기대사항에서 비롯되므로, 그 간극은 요구사항 프로세스에서 다루어야 합니다.
## 엔지니어링 원칙
프레임워크의 섹션 4는 개발자에게 코드 수준에서 직접 적용되는 원칙을 제공합니다:
- **경계 통제 원칙**: 시스템 내부의 유연성은 보존해야 할 엔지니어링 자산입니다. 모든 신뢰 경계에서의 통제는 강제해야 할 보안 요구사항입니다.
- **정규 입력 처리**: 입력을 진입 지점에서 정규화, 검증, 정제합니다. **정규 파싱 원칙**은 외부 입력을 경계에서 정규 내부 타입으로 파싱하며, 파싱이 성공하지 않으면 폐쇄적으로 실패(fail closed)합니다.
- **격리된 무결성 원칙**: 가격, 역할, 객체 상태와 같은 무결성 핵심 값은 권위 있는 서버 측 소스에서 도출됩니다. 이들은 클라이언트로부터 직접 수용되지 않습니다.
- **복원력 있는 코딩**: 방어적 코딩 관행은 예측 가능한 실행을 강제합니다. 여기에는 강력한 타입 지정, 신뢰 경계에서의 입력 검증, 출력 인코딩, 포괄적인 오류 처리, 안전한 리소스 관리, 우아하고 안전한 실패, 코드 수준에서의 최소 권한이 포함됩니다.
- **의존성 관리 책임**: 관계가 지속되는 동안 의존성을 선택, 통합, 모니터링, 유지할 때 SSEM 속성을 적용합니다.
## 보안 가능한 소프트웨어 엔지니어링 모델 (SSEM)
SSEM은 소프트웨어를 보안 가능하게 만드는 속성들을 정의합니다. 팀은 각 속성에 대한 목표를 설정하고, 시스템을 그 목표에 비추어 평가하며, 점진적으로 개선합니다. 속성들은 세 가지 범주로 구성됩니다:
| **유지보수성** | **신뢰성** | **복원력** |
|:--------------------|:-------------------:|----------------:|
| 분석 가능성 | 기밀성 | 가용성 |
| 수정 가능성 | 책임성 | 무결성 |
| 테스트 가능성 | 진정성 | 회복탄력성 |
| 관찰 가능성 | | |
SSEM은 설계상 권한 부여(Authorization) 속성을 두지 않습니다. 권한 부여는 요구사항으로 수집되고 인수 기준에 따라 구현되는 보안 기능입니다. 위의 속성들은 그러한 기능을 보안 가능하게 만드는 요소입니다. 프레임워크의 부록 A는 각 속성을 측정하는 접근 방식을 설명합니다.
## 저장소 내용
- [docs/securable_framework.md](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md): 전체 FIASSE 프레임워크와 SSEM 명세를 단일 문서로 제공합니다.
- [docs/framework/](https://github.com/owasp/fiasse/blob/main/docs/framework): 프레임워크를 섹션별로 하나의 파일로 분할한 것입니다. 이 섹션 파일들이 프레임워크의 기준 소스(source of truth)입니다. [코드 인덱스](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md)는 코드에 직접 적용되는 섹션과 프로세스, 역할, 도입 섹션을 구분합니다. [llms.txt](https://github.com/owasp/fiasse/blob/main/docs/framework/llms.txt)는 언어 모델을 위한 인덱스를 제공합니다.
- [skills/](https://github.com/owasp/fiasse/blob/main/skills): FIASSE와 SSEM을 AI 코딩 에이전트용 스킬로 패키징한 것입니다(아래 참조).
- TODO: FIASSE 방법론을 위한 구현 가이드
- 예제는 [Securability-Engineering/securable-framework-supplement](https://github.com/Securability-Engineering/securable-framework-supplement)로 이동되었습니다.
## 시작하기
1. [docs](https://github.com/owasp/fiasse/blob/main/docs) 디렉터리의 문서를 검토하십시오. [전체 프레임워크](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md)부터 시작하거나, [코드 인덱스](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md)를 사용하여 현재 다루는 코드에 적용되는 섹션을 찾으십시오.
2. 팀과 [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions)에서 개념과 원칙을 논의하십시오.
3. 요구사항 수집, 병합 리뷰, 프롬프트 엔지니어링 등 소프트웨어 엔지니어링 관행에 원칙을 적용하기 시작하십시오.
4. 프레임워크의 섹션 8에 있는 도입 단계를 따르십시오: 현재 관행을 평가하고, SSEM 용어를 통합하고, 핵심 영향력자를 식별하고, 팀을 교육 및 훈련하고, 역량 완화 수단으로 에이전트 기반 AppSec 도구를 도입하고, 협업을 촉진하고, 지속적으로 모니터링하고 개선하십시오.
- 보너스: 사용하는 IDE 또는 AI 기반 커맨드라인 에이전트(예: GitHub Copilot, Claude Code, OpenCode 등)에 맞는 플러그인을 설치하고 제공된 프롬프트를 사용하여 보안 가능한 코드를 생성하십시오. 프롬프트 라이브러리에서 "Securability Engineering" 또는 "FIASSE"를 찾아보십시오.
- FIASSE는 [OWASP Secure Agent Playbook](https://github.com/OWASP/secure-agent-playbook)의 일부로도 포함되어 있습니다.
## AI 코딩 에이전트용 스킬
[`skills/`](https://github.com/owasp/fiasse/blob/main/skills) 디렉터리는 [Agent Skills](https://code.claude.com/docs/en/skills) 형식을 지원하는 AI 코딩 에이전트(예: Claude Code)를 위해 FIASSE/SSEM을 바로 사용할 수 있는 스킬로 패키징합니다. 필요한 스킬 디렉터리를 에이전트의 스킬 경로에 복사하십시오.
- **[`securability`](https://github.com/owasp/fiasse/blob/main/skills/securability/SKILL.md)**: 열 가지 SSEM 속성과 핵심 원칙(No Static State of Secure, Isolated Integrity, Canonical Input Handling, Boundary Control, Least Astonishment)을 모두 다루는 간결하고 완전히 자립적인 참조 자료입니다. 일상적인 코드 생성 및 리뷰를 위한 기본값으로 사용하도록 의도되었습니다.
- **[`securable-code`](https://github.com/owasp/fiasse/blob/main/skills/securable-code/SKILL.md)**: 신뢰 경계 설계, 인증 시스템, 다중 서비스 데이터 흐름, 의존성 아키텍처 등 컨텍스트가 많고 아키텍처적으로 복잡한 작업을 위한 심층 분석 스킬입니다. 현재 다루는 코드와 관련된 특정 번들 프레임워크 섹션(`skills/securable-code/framework/` 내)으로 라우팅하여, 추가 컨텍스트를 대가로 소스 프레임워크의 전체 추론을 제공합니다.
기본적으로 `securability`를 사용하고, 설계 결정이 충분히 명확하지 않아 프레임워크 자체를 읽어야 할 필요가 있을 때는 `securable-code`를 사용하세요.
## 요약
이 저장소는 보안 가능한 소프트웨어(securable software)를 방어 가능한 상태로 유지되도록 구축된 소프트웨어로 정의합니다. 즉, 주변 환경이 변화하더라도 이해하고, 변경하고, 테스트하고, 강화할 수 있도록 구조화된 소프트웨어입니다. 이는 보안이 정적인 성취가 아니라 지속적인 과정임을 강조합니다. 또한 잘 설계된 소프트웨어의 내재적 품질 집합으로서 보안을 정립하는 SSEM(Securable Software Engineering Model)을 소개합니다. 이를 위해 유지보수성(Maintainability), 신뢰성(Trustworthiness), 그리고 복원성(Resilience)을 포함하는 안정성(Reliability)이라는 속성 범주를 제시합니다. FIASSE는 보안 실무를 가장 큰 영향을 미칠 수 있는 개발 워크플로에 통합할 것을 주장합니다. 이는 "보안은 나중에 생각하는" 접근이나 "시프트 레프트(shift left)" 접근에서 벗어나, 사전 예방적이고 협력적인 모델로 나아가는 것입니다. 제품 오너, 개발자, 보안 전문가가 설계의 가장 이른 단계부터 함께 작업하며, 특히 보안 요구사항 정의, 협력적 위협 모델링, 보안 인수 기준을 통해 협력합니다. 이는 코드 활동과 테스트에 대한 명확한 기대치를 설정합니다. 머지 리뷰는 게이트가 아니라 가드레일 역할을 합니다. 모든 머지는 권고성 Securability Report를 생성하며, 게이팅은 우회 경로가 있는 정책적 결정입니다. 검증 및 프로덕션에서 발견된 사항은 이를 예방할 수 있었던 상류 단계를 가리키는 경험적 인텔리전스로 취급됩니다. 소프트웨어 엔지니어에게는 유연성과 통제 사이의 균형을 맞추는 방법에 대한 지침이 제공됩니다. 또한 보안 결정을 내리기 위한 확정적인 모델도 제공됩니다. 궁극적으로 이는 모든 이해관계자가 더 견고하고 안정적이며 본질적으로 보안 가능한 시스템을 구축하는 데 기여할 수 있도록 역량을 부여합니다.
FIASSE는 개발자가 보안 전문가가 되거나 적대적 사고방식을 채택할 것을 요구하지 않는다는 점에서 기존 접근 방식과 다릅니다. 이는 원시 도구 출력을 개발자에게 그대로 떠넘기는 "쇼블링 레프트(Shoveling Left)"와 익스플로잇 우선 교육 같은 흔한 AppSec 안티패턴을 지목하고, 이를 실행 가능한 보안 인텔리전스 원칙(Actionable Security Intelligence Principle)으로 대체합니다. 이 접근 방식은 개발자의 인지 부하를 줄이는 동시에, 보안 실무자가 코드와 소프트웨어 엔지니어링 프로세스의 특정 속성을 통해 자신의 우려가 해결되었음을 확신할 수 있도록 하는 것을 목표로 합니다.
FIASSE는 개방적이고, 접근하기 쉬우며, 협력적인 것을 지향합니다.
## 로드맵
FIASSE 프로젝트의 초기 마일스톤:
- **프로젝트 기반**
- 프로젝트 거버넌스, 기여 가이드라인, 커뮤니케이션 채널 수립.
- **핵심 사양**
- 핵심 속성과 통합 전략을 상세히 다루는 FIASSE 프레임워크 및 SSEM 사양의 공식 발표.
- **도입 및 교육 자료**
- 모델과 그 적용을 소개하는 SSEM 입문서.
- 실질적 이점을 보여주는 초기 사용 사례 및 도입 패턴 모음.
- 구현 가이드, 예제 및 기타 교육 자료의 지속적 개발.
추가 마일스톤은 프로젝트 팀과 함께 개발될 예정입니다. 커뮤니티 의견은 [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions)를 통해 환영합니다.
## 보완 자료
이 저장소는 [FIASSE 웹사이트](https://fiasse.org)를 보완합니다.
[OWASP FIASSE](https://owasp.org/www-project-fiasse/) 프로젝트는 안전하지 않은 소프트웨어를 근절한다는 사명에 집중하는 비영리 단체인 [OWASP Foundation](https://owasp.org/)의 일부입니다. OWASP Foundation은 FIASSE의 원칙과 부합하는 풍부한 자료와 프레임워크를 제공합니다.
이 프레임워크는 보안 가능한 소프트웨어 엔지니어링(Securable Software Engineering)에 초점을 맞추고 있으며, 다른 OWASP 프로젝트들로 보완됩니다:
- 보안 기능 검증 및 즉시 사용 가능한 보안 요구사항 라이브러리: [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/)
- 보증 성숙도: [OWASP Software Assurance Maturity Model (SAMM)](https://owasp.org/www-project-samm/)
- 제품 보안 규정 준수: [OWASP Product Security Capability Framework (PSCF)](https://owasp.org/www-project-product-security-capability-framework/)
OWASP는 또한 [OWASP Mobile Application Security](https://mas.owasp.org/)와 같이 보안 요구사항과 기능을 문서화한 수많은 프로젝트를 운영하고 있습니다. [OWASP Developer Guide](https://owasp.org/www-project-developer-guide/)는 다양한 OWASP 리소스를 위한 포괄적인 자료입니다.
참조 요구사항과 보증 관행을 위한 또 다른 훌륭한 자료는 다양한 보안 프레임워크를 모아 매핑한 [OpenCRE](https://opencre.org/)입니다.
NIST SP 800-53, ISO/IEC 27001 Annex A, PCI DSS와 같은 통제 카탈로그는 위험 관리, 보증, 외부 평가를 지원합니다. FIASSE는 이들을 대체하지 않습니다. FIASSE는 이들을 요구사항 수집의 입력으로 취급하며, 여기서 카탈로그 통제는 개발이 구현하기 전에 인수 기준이 포함된 보안 요구사항으로 변환됩니다.
NIST [Secure Software Development Framework (SSDF)](https://csrc.nist.gov/publications/detail/sp/800-218/final)는 네 개 그룹으로 구성된 핵심 보안 소프트웨어 개발 관행 세트를 정의합니다. FIASSE는 그러한 관행 세트를 정의하지 않습니다. FIASSE는 소프트웨어 개발 수명주기에 보안을 통합하는 것을 강조함으로써 SSDF와 정렬됩니다.
NCSC의 [Software Security Code of Practice](https://www.ncsc.gov.uk/collection/software-security-code-of-practice-implementation-guidance)는 원하는 결과와 몇 가지 핵심 전략을 정의합니다. FIASSE는 보안 가능한 결과를 달성하기 위한 1차 수준의 후속 원칙과 전략에 초점을 맞추며, 개발 및 보증 팀이 비즈니스 전략과 정렬하도록 의도되었습니다. SSEM은 원하는 결과를 산출하는 데 사용되는 속성을 명시하며, FIASSE 방법론은 소프트웨어 엔지니어링 관행에서 이러한 속성을 구현하기 위한 실용적인 지침을 제공합니다.
카네기멜런 대학교의 [CERT](https://www.cert.org/) Secure Coding Standards는 취약한 코드 패턴을 보여주는 "하지 말아야 할 것" 예제와 "해야 할 것" 예제를 모두 제공하는 언어 수준 규칙 세트입니다. FIASSE는 프로그래머가 보안 가능한 코드 이면의 "왜?"를 이해하도록 돕는 원칙 기반 접근 방식을 제공함으로써 이러한 규칙을 보완합니다.
Software Factory Security Framework([SF2](https://sf2framework.com/))는 "보안 리더에게 비즈니스 성과를 개선하면서 보안 역량을 확장하기 위한 전략적 접근 방식을 제공합니다." 이는 소프트웨어 엔지니어링 관행에 초점을 맞춘 FIASSE를 보완하는 조직 수준의 프레임워크입니다.
## 기여
문서와 예제를 개선하기 위한 기여를 환영합니다. 자세한 내용은 [기여 가이드라인](https://github.com/owasp/fiasse/blob/main/CONTRIBUTING.md)을 참조하십시오.
## 라이선스
Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) - 자세한 내용은 [LICENSE](https://github.com/owasp/fiasse/blob/main/licence.txt) 파일을 참조하십시오.
## 감사의 말
이 프로젝트는 OWASP 커뮤니티의 협력적 노력입니다. 소프트웨어 보안 개선에 기여한 모든 기여자의 소중한 의견과 헌신에 감사드립니다.
이 프로젝트에 참여한 [기여자 목록](https://github.com/owasp/fiasse/blob/main/CONTRIBUTORS.md)이 있습니다. 일부 초기 기여자는 초기 개념을 형성하고 아이디어를 레드팀하는 데 도움을 주었습니다.