정적 분석이란 무엇일까요?

정적 분석이란?

정적 분석은 애플리케이션을 실행하지 않고도 소스 코드를 자동으로 분석하는 것입니다.

프로그램 실행 중에 분석을 수행하는 경우 이를 동적 분석이라고 합니다.

정적 분석은 주로 다음을 탐지하는 데 사용됩니다.

• 보안 취약성.
• 성능 문제.
• 표준을 준수하지 않음.
• 오래된 프로그래밍 구조 사용.

정적 분석 도구는 어떻게 작동하나요?

모든 정적 분석 도구에 공통적인 기본 개념은 소스 코드를 검색하여 관련 경고나 정보가 있는 특정 코딩 패턴을 식별하는 것입니다.

이것은 “JUnit 5 테스트 클래스는 '공개'일 필요가 없습니다”와 같이 간단할 수 있습니다.또는 “SQL 실행 명령문에서 사용되는 신뢰할 수 없는 문자열 입력”과 같이 식별하기 복잡한 것일 수도 있습니다.

정적 분석 도구는 이 기능을 구현하는 방법이 다릅니다.

• 추상 구문 트리 (AST) 를 생성하는 소스 코드 파싱 기술
• 텍스트 정규 표현식 매칭,
• 위의 조합입니다.

텍스트에 대한 정규 표현식 일치는 매우 유연하고 일치하는 규칙을 작성하기 쉽지만, 종종 많은 오탐으로 이어질 수 있으며 일치 규칙은 주변 코드 컨텍스트를 무시합니다.

AST 매칭은 소스 코드를 텍스트로 채워진 파일뿐만 아니라 프로그램 코드로 취급하므로 보다 구체적이고 상황에 맞는 매칭이 가능하고 코드에 대해 보고되는 오탐의 수를 줄일 수 있습니다.

지속적 통합에서의 정적 분석

정적 분석은 종종 지속적 통합 (CI) 프로세스 중에 수행되어 규정 준수 문제에 대한 보고서를 생성하며, 이 보고서를 검토하여 시간이 지남에 따라 코드베이스를 객관적으로 파악할 수 있습니다.

일부 사용자는 정적 분석 도구를 코드의 특정 부분만 측정하고 규칙의 하위 집합에 대해서만 보고하도록 구성하여 코드 품질의 객관적인 척도로 사용합니다.

시간이 지나도 코드 평가가 달라지지 않기 때문에 사용된 규칙에 따라 객관성이 보장됩니다.분명히 사용되는 규칙과 그 구성을 조합하는 것은 주관적인 결정이며 팀마다 시기에 따라 다른 규칙을 사용하기로 선택합니다.

CI에서 정적 분석을 수행하는 것은 유용하지만 프로그래머에 대한 피드백이 지연될 수 있습니다.프로그래머는 코딩할 때 피드백을 받지 않고 나중에 정적 분석 도구를 통해 코드를 실행할 때 피드백을 받습니다.CI에서 정적 분석을 실행할 때의 또 다른 부작용은 결과를 무시하기 쉽다는 것입니다.

팀이 정적 분석의 결과에 더 많은 관심을 기울일 수 있도록 지표가 초과되는 경우 (예: 트리거된 규칙 수) 빌드에 실패하도록 빌드 프로세스에서 임계값 지표를 구성하는 것이 일반적으로 가능합니다.

IDE에서의 정적 분석

피드백을 더 빨리 받기 위해 필요에 따라 또는 코드가 변경될 때 주기적으로 IDE에서 정적 분석 규칙을 실행하는 많은 IDE 플러그인이 있습니다.

그러면 프로그래머가 코드를 작성할 때 IDE에서 규칙 위반을 확인할 수 있으며, 규칙을 무시하기 어렵게 만들기 위해 편집기에서 밑줄이 그어진 코드로 렌더링되도록 위반을 구성할 수 있습니다.

저는 개인적으로 이것이 코딩을 개선하는 데 유용한 방법이라고 생각합니다. 특히 정적 분석 도구에서 다루는 새 라이브러리로 작업할 때 더욱 그렇습니다.오탐이나 관심 없는 규칙으로 인해 '잡음이 심할 수도 있지만요.하지만 이 문제는 추가 단계를 수행하여 특정 규칙을 무시하도록 정적 분석 도구를 구성함으로써 해결됩니다.

정적 분석 규칙을 기반으로 코드 수정

대부분의 정적 분석 도구에서는 규칙 수정이 프로그래머에게 맡겨져 있으므로 프로그래머는 규칙 위반의 원인과 수정 방법을 이해해야 합니다.

위반 사항을 수정할 수 있는 기능이 포함된 정적 분석 도구는 거의 없습니다. 수정은 팀과 사용된 기술, 합의된 코딩 스타일에 따라 결정되는 경우가 많기 때문입니다.

기본 규칙

정적 분석 도구가 기본 규칙과 함께 제공될 때 규칙의 품질에 대한 잘못된 확신이 생길 수 있습니다. 프로그래머가 직면할 수 있는 모든 문제와 해당 규칙이 적용되어야 하는 모든 상황을 포괄한다고 믿기 쉽습니다.때로는 규칙을 적용해야 하는 상황이 미묘하고 감지하기 쉽지 않을 수 있습니다.

정적 분석 도구를 사용하여 규칙과 위반 사항을 더 자세히 조사함으로써 프로그래머가 특정 영역의 컨텍스트에서 문제를 감지하고 방지하는 기술을 개발할 수 있기를 바랍니다.

도메인에 컨텍스트 규칙이 필요한 경우 정적 분석 도구에는 도메인 또는 라이브러리와 일치하는 규칙이 없을 수 있으며, 또한 도구를 구성하고 확장하기가 어려울 수 있습니다.

성가심

이러한 '성가심' 중 극복할 수 없는 것은 없습니다.

• 오탐지
• 수정 사항 부족
• 규칙을 무시하기 위한 구성
• 컨텍스트별 규칙 추가

하지만 애초에 정적 분석 도구를 사용하지 않기 위한 핑계로 사용되는 경우가 많은데, 정적 분석을 사용하면 다음과 같은 방법으로 매우 유용할 수 있기 때문에 안타깝습니다.

• 주니어 개발자를 위한 더 나은 접근 방식 강조
• 명확한 코딩 위반에 대한 빠른 피드백 확보
• 프로그래머가 이전에 경험하지 못한 애매한 문제를 식별합니다.
• 프로그래머가 올바른 코딩 접근 방식을 채택했음을 강조하십시오 (위반 사항이 보고되지 않은 경우)

IDE 기반 정적 분석 도구

프로젝트의 개인 기여자로서 저는 IDE 내에서 실행되는 정적 분석 도구를 즐겨 사용하므로 코드에 대한 피드백을 빠르게 받을 수 있습니다.

이는 프로젝트에 있을 수 있는 모든 풀 리퀘스트 검토 프로세스와 CI 통합을 보완합니다.

저는 우위를 점할 수 있는 도구를 찾고 개인의 워크플로를 개선하려고 노력합니다.

도구가 IDE에서 실행되는 경우 기본 GUI와 구성 접근 방식이 동일하기 때문에 도구를 서로 바꿔서 보고 싶어질 수 있습니다.

도구에는 중복되는 기능이나 규칙 집합이 있을 수 있지만 이점을 최대한 활용하기 위해 여러 도구를 설치하여 장점을 활용합니다.

코딩할 때 적극적으로 사용하는 정적 분석 IDE 도구는 다음과 같습니다.

• 내장 IntelliJ 검사 - 일반적인 코딩 패턴
• 스팟 버그 - 일반적인 오류
• 소나린트 - 일반적인 사용 패턴
• 체크스타일 - 일반적인 스타일 패턴
• 시큐어 코드 워리어의 Sensei - 사용자 지정 규칙 생성

서로 잘 어울려서 서로를 보강하고 보완하기 때문에 모두 사용합니다.

인텔리제이 인스펙션

IntelliJ를 사용하는 경우 이미 해당 검사를 사용하고 있는 것입니다.

이는 IDE에서 플래그가 지정된 정적 분석 규칙입니다.이들 중 일부에는 문제를 해결하기 위해 코드를 다시 작성할 수 있는 QuickFix 옵션도 있습니다.

규칙을 설정하거나 해제할 수 있으며 IDE에서 강조 표시할 때 사용할 오류 수준을 선택할 수 있습니다.

훌륭한 IntelliJ 검사 기능이 많이 있습니다.제가 이 글을 쓰면서 그 내용을 다 읽었기 때문에 알아요.IntelliJ Inspections를 기본값으로 사용하고 아직 구성하지 않았습니다. 하지만 검사를 최대한 활용하려면 검사를 꼼꼼히 읽고 자신의 코딩 스타일과 관련된 항목을 식별하고 코드에서 확인할 수 있도록 경고 수준을 구성해야 합니다.

IntelliJ Inspecing의 좋은 점은 IDE와 함께 무료로 제공되며 다음과 같은 근육 기억을 구축하는 데 도움이 된다는 것입니다.

• 코드를 작성할 때 소스의 경고 및 오류 확인
• 플래그가 지정된 코드 위에 마우스를 올려 놓으면 규칙 위반 여부를 알 수 있습니다.
• Alt+Enter를 사용하여 문제에 대한 QuickFix를 적용합니다.

스팟 버그

더 스팟 버그 IntelliJ 플러그인은 정적 분석을 사용하여 코드의 버그를 알려줍니다.

IntelliJ 기본 설정에서 SpotBugs를 구성하여 코드를 스캔할 수 있습니다. 사용된 실제 규칙은 Detector 탭에서 찾을 수 있습니다.

저는 코드를 작성하고 검토한 후 SpotBugs를 사용하는 경향이 있습니다. 그런 다음 '테스트 소스를 포함한 프로젝트 파일 분석'을 실행하겠습니다.

이렇게 하면 버그, 데드 코드 및 명백한 최적화를 식별하는 데 도움이 됩니다.또한 어떤 조치를 취해야 할지 결정하는 데 도움이 되도록 신고된 위반 사항 중 일부를 조사해야 합니다.

SpotBugs는 문제를 찾지만 문제 해결을 시도하기 위한 QuickFix 작업을 제공하지 않습니다.

SpotBugs는 구성하기 쉬우며 제 IDE에서 참고할 수 있는 객관적인 2차 의견이라고 생각합니다.

소나 린트

더 소나 린트 플러그인.

IntelliJ 기본 설정에서 SonarLint를 구성하여 코드의 유효성을 검사할 규칙을 선택할 수 있습니다.

기본적으로 SonarLint는 실시간으로 실행되며 편집 중인 현재 코드에 대한 문제를 보여줍니다.

SonarLint는 빠른 수정 기능을 제공하지 않지만 위반 보고서와 관련된 문서는 일반적으로 명확하고 잘 문서화되어 있습니다.

SonarLint는 과거에 최신 버전의 Java에서 알고 있던 새로운 Java 기능을 알려주는 데 유용하다는 것을 알게 되었습니다.

체크 스타일

더 체크 스타일 플러그인은 서식 및 코드 품질 규칙의 혼합을 제공합니다.

체크스타일 플러그인은 '썬 체크' 및 '구글 체크'와 함께 제공됩니다.

이들의 정의는 간단할 수 있습니다. 온라인에서 찾음.

CheckStyle은 프로젝트가 자체 규칙 세트를 만드는 데 시간을 할애했을 때 가장 큰 가치를 더합니다.그러면 해당 규칙 세트를 사용하도록 IDE 플러그인을 구성할 수 있으며 프로그래머는 코드를 CI에 커밋하기 전에 스캔을 수행할 수 있습니다.

CheckStyle은 CheckStyle 위반 수가 임계값을 초과할 때 CI 프로세스의 빌드 실패 플러그인으로 자주 사용됩니다.

선생

선생 코드 매칭 및 QuickFixs 생성을 위해 AST (추상 구문 트리) 를 기반으로 하는 정적 분석을 사용하므로 문제가 있는 코드를 매우 구체적으로 식별할 수 있습니다.

AST를 사용하면 레시피와 관련된 QuickFixs가 주변 코드를 이해할 수 있습니다. 예를 들어 코드에 새 클래스를 추가할 때 해당 클래스에 대한 가져오기는 소스 파일에 한 번만 추가되며 각 교체에는 추가되지 않습니다.

Sensei는 다른 도구에서는 존재하지 않거나 구성하기 어려운 사용자 지정 매칭 규칙을 쉽게 만들 수 있도록 만들어졌습니다.

구성 파일을 수정하는 대신 GUI에서 모든 구성을 수행할 수 있습니다.새 레시피를 만들 때 GUI를 사용하면 레시피가 일치하는 코드를 쉽게 확인할 수 있습니다.또한 QuickFixs를 정의할 때 코드의 이전 상태와 이후 상태를 즉시 비교할 수 있습니다.따라서 상황에 맞는 레시피 (예: 팀, 기술, 심지어 개별 프로그래머만 사용할 수 있는 고유한 레시피) 를 쉽게 만들 수 있습니다.

저는 Sensei를 다른 정적 분석 도구와 함께 사용합니다. 예를 들어 대부분의 정적 분석 도구는 문제를 발견하지만 해결하지는 못합니다.Sensei의 일반적인 사용 사례는 Sensei에서 다른 도구의 매칭 검색을 복제하고 Quick Fix로 확장하는 것입니다.이렇게 하면 적용된 사용자 지정 수정이 이미 프로젝트의 코딩 표준을 충족한다는 이점이 있습니다.

IntelliJ 인텐션 세트에 이미 있는 Sensei 레시피를 만드는 경우가 있는데, 이는 인텐션 보고서가 제가 만든 컨텍스트와 완전히 일치하지 않거나 IntelliJ에서 제공하는 QuickFix가 사용하려는 코드 패턴과 일치하지 않기 때문입니다.

저는 기존 도구를 완전히 교체하는 대신 기존 도구를 보강하는 편입니다.

Sensei는 공통 규칙의 상황별 변형을 식별할 때도 매우 유용할 수 있습니다. 예를 들어 정적 분석 도구에서 지원하지 않는 SQL 라이브러리를 사용하지만 정적 분석 엔진의 일반 SQL 규칙이 여전히 적용되는 경우 Sensei를 사용하여 해당 규칙의 라이브러리별 변형을 만들 수 있습니다.

Sensei는 앞서 언급한 정적 분석 도구와 같은 일반적인 레시피를 많이 제공하는 것은 아닙니다. Sensei의 강점은 특정 코딩 스타일 및 사용 사례에 맞게 구성된 QuickFix를 갖춘 새로운 레시피를 쉽게 만들 수 있다는 것입니다.

참고: 우리는 일반적인 사용 사례를 다루기 위해 레시피의 공개 저장소를 개발 중입니다. 여기에서 찾을 수 있습니다.

요약

저는 함께 작동하고 구성 가능하며 특정 상황에 맞게 쉽게 확장할 수 있는 도구를 선택하는 경향이 있습니다.저는 문제를 식별하고 제가 사용하는 프로그래밍 언어와 라이브러리에 대해 자세히 알아보는 데 도움이 되는 IDE의 정적 분석 도구를 수년간 사용해 왔습니다.

앞서 언급한 모든 도구를 조합하여 사용합니다.

• IntelliJ Intentions는 흔히 관련된 QuickFix를 사용하여 일반적인 코드 문제를 즉시 파악할 수 있도록 도와줍니다.
• SpotBugs는 제가 놓쳤을 수도 있는 간단한 버그를 찾아 성능 문제를 알려줍니다.
• SonarLint는 제가 몰랐던 Java 기능을 식별하고 코드를 모델링할 수 있는 추가 방법을 알려주죠.
• CheckStyle을 사용하면 CI 중에도 적용되는 합의된 코딩 스타일을 준수할 수 있습니다.
• Sensei는 QuickFixs를 생성하여 정적 분석 도구에서 발견되는 일반적인 시나리오를 보완하고 다른 도구로는 구성하기 어려운 특정 프로젝트 또는 기술 레시피를 만들 수 있도록 도와줍니다.

---

IntelliJ 내에서 “환경설정\ 플러그인” (Mac) 또는 “설정\ 플러그인” (Windows) 을 사용하여 Sensei를 설치한 다음 “센세이 보안 코드”를 검색하면 됩니다.

Secure Code Warrior GitHub 계정의 `sensei-blog-examples` 프로젝트에서 일반적인 사용 사례에 대한 예제 코드 및 레시피 저장소를 찾을 수 있습니다.

https://github.com/securecodewarrior/sensei-blog-examples

Sensei에 대해 더 알아보기