1212 오픈 소스 사용 체크리스트

저작자가 되면 좋은 이유

• 사용중인 오픈소스 프로젝트에 코드를 구현해서 컨트리뷰트 PR : 기능 수정, 추가 욕심
• 컨트리뷰트 PR : 우선순위에 따라서 반려
• 오픈소스 프로젝트 fork해서 별도의 프로젝틀 내가 직접 운영
  => 저작자 시작
  => 기존 프로젝트 라이선스 신경
• 프로젝트의 성장 도모
• 함께 공유, 개선, 아이디어 추가

저작자가 되는 방법

npm

아무 프로젝트 라이선스 달면 오픈 소스! (ex.MIT)
readme
contributing
중복이 아닌 명확한 프로젝트 이름 (ex. is-null-or-not)

저작자 체크 리스트

• readme
  • 프로젝트 만든 이유, 목적, 사용 용도 추천
  • 코드 사용 방법 / 설치 사용 방법
• contributing
  • 가이드(다른 프로젝트 참고) : 환영 메세지
• LICENSE
  • 라이선스 전문
• 중복이 아닌 명확한 프로젝트 이름 (ex. is-null-or-not)
  • 상표권 침해 안하고 기능 명확해야 함
• 코드
  • 이해하기 쉬운 코드(*명명법), 주석 설명 깔끔, 데드 코드 정리, 민감 정보 제외
• 만약 회사 프로젝트 : 사내 법무팀, 오픈소스 담당 팀 자문 / 담당자 추가 / 외부에 바로 오픈 x(사내 오픈 먼저)

오픈 소스 사용 체크리스트

금융권: 시큐어 코딩, 오픈소스 활용/관리 안내서 by 금융감독원, 금융보안원
[개발 전]

1. 오픈 소스에 대한 사전 기능 및 보안성 테스트
   : 기능, 보안성, 이슈 현황 파악
   : 취약점 확인, 기관 연락 검토 요청 => 신뢰성 검증
2. 라이선스 검토
   : 라이선스를 사용함으로써 지켜야 하는 규정, 준수 검토
   : 위약금, 법적 문제 => 사내 법무팀 자문 요청

[개발 중]

1. 취약점 최소화 : 보안 정책팀 협업 => 인증, 주요 기능 보안 강화
2. 대체 수단 확보 : 예외, 법적 이슈 발생 => 대비책
3. 자체 대응 및 추가 개발 역량 확보 : 충분한 이해, 기술력 = 문제 해결 능력 갖춤

[개발 후]

1. 모니터링 : 오픈 소스 현황, 취약점 업데이트
2. 오픈소스 보안패치 : 확인, 취약점 최소화, 적용
3. 오픈소스 종속성 검사 : 문제 발생, 최대한 빠른 해결
4. 기능 및 보안성 테스트 : 테스트 부서, 보안 팀과 협업 통해 지속적 테스트, 분석