시큐어코딩 Rule 수천 개, 이걸 진짜 다 검증한다고?— 자동차 보안 V&V의 현실

현업에서 보는 차량 보안 V&V

시리즈 전체 구성

1

이전 글

자동차 사이버보안, 왜 갑자기 이렇게 복잡해졌나

SDV·OTA·Connected Car 시대의 보안 요구사항

DONE

2

이전 글

ISO/SAE 21434 — 실무자가 진짜 알아야 할 것들

표준이 요구하는 것과 현업의 현실

DONE

3

지금 읽는 글

시큐어코딩 Rule 수천 개, 이걸 진짜 다 검증한다고?

자동차 보안 V&V의 현실

NOW

4

다음 글

TARA, 위협 분석을 현업에서 어떻게 하나

실제 프로젝트에서 TARA가 굴러가는 방식

NEXT

5

예정

OTA 보안 — Secure Flash의 현실

무선 업데이트 보안 구현의 복잡성

SOON

현장에서 자주 듣는 말

"MISRA 몇 천 개 나왔는데 이거 다 대응해야 하나요?"

"Static Analysis 결과가 수만 건인데 현실적으로 가능한가요?"

"Required Rule까지 포함하면 일정이 안 나옵니다."

"어차피 다 못 하면 중요한 것만 하면 되는 거 아닌가요?"

이 말들, 현장에서 정말 자주 듣습니다. 그리고 질문 뒤에는 늘 이런 기대가 숨어 있습니다.

"현실적으로는 다 안 해도 되는 거 아닌가요?"

결론부터 말하겠습니다. 다 해야 합니다. 단, "어떻게 다 하느냐"가 문제입니다. 그리고 그게 현업의 전부입니다.

시큐어코딩은 "개발자가 조심해서 코딩하는 것"이 아닙니다. ISO/SAE 21434 체계에서 시큐어코딩은 보안 요구사항의 구현이고, 그 구현을 검증 가능하게 증명하는 것은 선택이 아니라 의무입니다.

---

왜 Rule이 수천~수만 개가 될까

혼자 ECU 코드 한 줄 짜는 게 아닙니다. 실제 ECU 프로젝트에는 이것들이 모두 들어옵니다.

ℹ️ 실무에서 쌓이는 대응 항목들

MISRA C/C++  ·  CERT C/C++  ·  CWE 매핑  ·  ISO/SAE 21434 보안 요구사항
Static Analysis 결과  ·  Compiler Warning  ·  OEM 자체 Coding Rule  ·  보안 사고 재발 방지 항목

문제는 이것들이 한꺼번에 오지 않는다는 점입니다. MISRA가 자리 잡으면 OEM 추가 Rule이 붙습니다. 21434 대응을 시작하면 CWE 매핑이 추가됩니다. 보안 이슈가 한 번 터지면 재발 방지 항목이 또 쌓입니다. 결국 수만 개가 됩니다.

그런데 여기서 숫자를 더 크게 만드는 주범이 따로 있습니다.

서드파티 코드가 숫자를 부풀린다

ECU 개발에는 MCU 제조사의 HAL Driver, RTOS, CMSIS 같은 벤더 코드가 반드시 들어갑니다. 이 코드들은 수천만 기기에서 이미 검증됐지만, MISRA 관점에서는 위반 덩어리일 수 있습니다.

❌ 툴에서 나온 위반은 전부 우리가 고쳐야 한다

✅ 벤더 코드에서 발생한 위반은 대응 방식이 다르다

HAL Driver에서 나온 미사용 매크로 수천 건을 우리 코드처럼 직접 수정하는 건 불가능합니다. 벤더 코드에 대한 스코프 정의와 Deviation 정책을 프로젝트 초반에 확정해야 합니다. 이게 없으면 숫자에 묻혀 진짜 중요한 위반을 놓칩니다.

---

"다 한다"는 게 무슨 의미인가

수만 건을 "다 한다"는 게 수만 건 전부 코드를 수정한다는 뜻이 아닙니다. 다 한다는 건 수만 건 각각에 대해 판단하고, 그 판단을 문서로 남긴다는 뜻입니다.

대응 방식	내용	주의점
Fix	코드를 실제로 수정한다	가장 깔끔하지만 항상 가능한 건 아니다
Deviation	이 케이스에서 Rule 적용 제외 선언	기술적 근거 문서화 필수. 건별로 필요하다
False Positive	실제 취약점이 아님을 분석·기록	"왜 위험하지 않은가"까지 설명해야 한다
Risk Acceptance	잔존 위험을 인정하고 수용	승인자 서명 필요. 근거가 명확해야 한다
Compensating Control	직접 수정 대신 다른 방어 수단 제시	대안의 유효성을 별도로 증명해야 한다

Fix는 오히려 쉬운 편입니다. 진짜 어려운 건 Deviation과 False Positive 분석입니다. RTOS 내부 코드에서 나온 "Potential NULL Pointer Dereference" — 이게 실제 위험인지, 코드 구조상 도달 불가능한 경로인지 판단하고, 그 판단 근거를 문서로 남겨야 합니다.

💡 현업에서 시큐어코딩 공수의 대부분은 코드 수정이 아니라
분석, 판단, 문서화에서 소모됩니다.

---

MISRA Mandatory vs Required — 이 구분이 왜 중요한가

❌ Required도 Mandatory처럼 전부 Fix해야 한다

✅ Required는 Deviation이 가능하다 — 단, 건별 기술 근거가 필요하다

Mandatory는 명확합니다. 무조건 Fix입니다. Required는 이론상 Deviation이 가능하지만, 위반이 수천 건이면 수천 건 각각에 기술적 근거를 문서화해야 합니다. Advisory는 선택이지만 OEM이 "우리 프로젝트에서는 Advisory도 Required 수준으로 관리해라"고 하면 그냥 Required가 됩니다.

⚠️ OEM마다 Rule 해석이 다릅니다.
프로젝트 초기에 "어떤 Rule을 어느 수준으로 적용할 것인가"를 명확히 합의하지 않으면 후반에 일정이 터집니다.

---

이걸 다 하는 게 가능한 이유 — Traceability 체계

수만 건을 혼자 다 검토한다? 불가능합니다. 하지만 체계를 갖추면 가능합니다. ISO/SAE 21434가 요구하는 것도 결국 이 체계입니다.

시큐어코딩 V&V Traceability 흐름

1

보안 Requirement 정의 — MISRA·CWE·OEM Rule 기반으로 "무엇을 지켜야 하는가"를 문서화

2

구현 — Requirement를 반영한 코딩. 초반에 체계를 잡으면 위반 수 자체가 줄어든다

3

Static Analysis 수행 — Coverity·Polyspace 등으로 위반 탐지. 이 결과가 Audit Evidence의 시작이다

4

Violation 분류 및 처리 — Fix / Deviation / False Positive / Risk Acceptance — 건별 판단 및 문서화. 가장 오래 걸리는 단계

5

Evidence 생성 및 Audit 대응 — 리포트·판단 근거·Deviation 문서 정리. "우리는 알고 있었고, 이렇게 판단했다"를 증명한다

Static Analysis 리포트는 목적이 아닙니다. Audit에서 "우리는 이걸 알고 있었고, 이렇게 판단했다"를 보여주는 수단입니다. 리포트를 내면 끝이 아니라, 리포트가 4번과 5번의 입력값이 됩니다.

✅ "다 해야 한다"는 건 수만 건을 전부 Fix하라는 게 아니라,
수만 건 각각에 대해 판단하고 그 판단을 추적 가능하게 남기라는 뜻입니다.

---

그래서 현업은 어떻게 굴러가나

체계 없이 뛰어들면 이렇게 됩니다. Static Analysis 돌림 → 수만 건 나옴 → 멘붕 → 중요한 것과 안 중요한 것이 뒤섞임 → 일정 초과 → OEM Audit에서 Evidence 부족 지적.

체계가 있으면 다릅니다.

• 벤더 코드 스코프를 미리 정의해 제외하거나 일괄 Deviation 처리
• Mandatory 먼저, Required 중 ASIL 영향 높은 것 다음, Advisory는 정책에 따라
• False Positive는 패턴화해서 반복 처리 속도를 높인다
• CI/CD 파이프라인에 SAST 연계 — 코드가 올라올 때마다 자동 탐지
• Deviation 템플릿화 — 근거 작성 시간을 단축한다

SDV 시대에 수백만 라인으로 늘어나는 코드에서 수작업으로만 관리하는 건 구조적으로 한계가 옵니다. 자동화 없이는 "다 한다"는 게 불가능해지는 시점이 반드시 옵니다.

---

현업에서는 이렇게 느낀다

현업 경험 4가지

공수는 Fix보다 문서화에서 더 나간다 — 코드 한 줄 고치는 건 5분이지만, "왜 이게 실제 위험이 아닌가"를 기술 근거와 함께 Deviation 문서로 작성하는 건 훨씬 오래 걸린다. Audit을 경험해본 사람은 안다.

벤더 코드 처리 전략이 없으면 숫자에 묻힌다 — MCU HAL Driver, RTOS에서 나온 위반 수천 건을 구분 없이 다 처리하려다가 진짜 중요한 위반을 못 보는 경우가 생긴다. 스코프 정의가 먼저다.

OEM 합의는 프로젝트 초반에 해야 한다 — 중반에 "우리는 Required도 다 Mandatory처럼 보겠다"는 말이 나오면 일정이 흔들린다. Rule 적용 수준은 초반에 명문화해두는 것이 맞다.

자동화 없이는 유지 불가능한 구조가 온다 — 지금은 버텨도, SDV로 갈수록 코드 규모가 커진다. CI/CD 연계 SAST와 Deviation 템플릿화가 선택이 아니라 필수가 되는 시점이 온다.

---

마무리

시큐어코딩 Rule 수천 개, 이걸 진짜 다 검증해야 합니다.

단, "다 검증한다"는 건 수만 건을 전부 Fix하는 게 아니라,
수만 건 각각에 대해 판단하고 그 판단을 추적 가능하게 남기는 것입니다.

MISRA, CWE, Static Analysis, ISO/SAE 21434. 이 모든 것들은 결국 "이 ECU가 신뢰할 수 있는가"를 증명하기 위한 과정입니다.

그 증명의 핵심은 "우리는 몰랐다"가 아니라 "우리는 알고 있었고, 이렇게 판단했다"를 Audit에서 보여주는 것입니다. 시큐어코딩 체계는 그것을 가능하게 만드는 구조입니다.

핵심 요약

1

시큐어코딩 Rule은 다 검증해야 한다 — Fix든, Deviation이든, False Positive 분석이든 건별 판단과 문서화가 의무다

2

공수의 대부분은 분석·문서화에서 나간다 — 코드 수정보다 "왜 이 판단을 했는가"를 남기는 게 더 오래 걸린다

3

벤더 코드 처리 전략을 초반에 확정해야 한다 — 스코프 없이 시작하면 숫자에 묻혀 진짜 중요한 것을 놓친다

4

OEM과 Rule 수준 합의는 프로젝트 초반에 한다 — 중반에 기준이 바뀌면 일정이 터진다

5

SDV 시대에는 자동화 없이 유지가 어렵다 — CI/CD 연계 SAST와 Deviation 템플릿화가 필수가 되는 시점이 온다

시큐어코딩 MISRA CWE StaticAnalysis ISO21434 자동차사이버보안 V&V SAST SDV FalsePositive Deviation Traceability