병합 전에 SQL 인젝션 탐지.

SQL 인젝션이 로컬 우선 코드 리뷰에 어떻게 맞는지, Code Radar가 어떤 증거를 만들고 어디까지 지원하며 신뢰한 발견을 CI로 옮기는지 알아보세요.

radar scan . --quick

여기서 SQL 인젝션이 의미하는 것.

SQL 인젝션 규칙은 악용 가능한 동작을 만들거나 중요한 유지보수 위험을 숨길 수 있는 패턴을 찾고 위치, 심각도, 신뢰도, 수정 컨텍스트를 제공합니다.

확인할 근거

“병합 전에 SQL 인젝션 탐지.”을 의사결정 범위로 삼아 설치나 구매 전에 입력, finding 상세 정보, workflow 전달 과정, 제품 경계를 확인하세요.

기준확인할 근거경계
입력 범위선택한 파일, 설정, 스캔 모드, 활성 규칙.포함된 경로와 설정된 검사만 평가합니다.
발견 상세파일, 줄, 규칙 ID, 심각도, 설명, 수정 방향.설명용 출력은 사용자의 저장소 결과가 아닙니다.
워크플로 전달로컬 결과, 보고서, 에이전트 컨텍스트, 선택적 CI 신호.워크플로에 필요할 때만 내보내기나 CI를 활성화하세요.
결정 적합성도구나 플랜 선택 전에 실제 저장소에 같은 기준을 적용하세요.보편적 승자나 보장된 결과를 주장하지 않습니다.

이 위험을 로컬에서 검사

범위와 구체적인 신호

SQL 인젝션은 범주 이름보다 아래의 구체적인 범위를 확인해야 합니다. 초점: 소스 보안; RADAR-SEC-SQLI, 소스 보안.

  • 대상: 병합 전에 이 위험을 이해해야 하는 개발자: SQL 인젝션.
  • 결과를 신뢰하기 전에 확인할 증거.: 정확한 파일 위치, 규칙 컨텍스트, 심각도, 신뢰도, 수정 지침. RADAR-SEC-SQLI, 소스 보안. 같은 발견 집합에서 생성된 터미널 출력과 SARIF, JSON, HTML 아티팩트.
  • 경계: 정적 탐지는 증거이지 악용 가능성의 증명은 아닙니다. 데이터 흐름과 런타임 맥락을 확인하고 오탐을 문서화하며 수정 동작을 테스트하세요.
  • 규칙 ID: RADAR-SEC-SQLI

위험한 패턴 / 더 안전한 패턴

SQL 인젝션: 유용한 결과는 개발자에게 설명 가능하고 다음 리뷰 단계로 이동할 수 있어야 합니다. 팀 정책을 바꾸기 전에 아래 증거를 확인하세요.

위험한 패턴더 안전한 패턴
db.query(`SELECT * FROM users WHERE id = ${id}`);db.query("SELECT * FROM users WHERE id = ?", [id]);

로컬 신호에서 공유 게이트까지.

SQL 인젝션: 가치를 입증하는 가장 작은 흐름부터 사용하세요. 이후 단계는 팀이 이미 이해한 증거를 재사용해야 합니다. 정확한 파일 위치, 규칙 컨텍스트, 심각도, 신뢰도, 수정 지침. RADAR-SEC-SQLI, 소스 보안. 같은 발견 집합에서 생성된 터미널 출력과 SARIF, JSON, HTML 아티팩트.

단계명령 또는 작업결정
1빠른 로컬 스캔 실행신호가 유용한가?
2발견 검토 및 수정수정이 구체적이고 재현 가능한가?
3이식 가능한 증거 내보내기리뷰에 SARIF, JSON, HTML 중 무엇이 필요한가?
4신뢰한 임계값을 CI로 확장어떤 심각도가 PR을 막아야 하는가?
radar scan . --quick
radar scan . --format sarif --fail-on high

자신의 코드에서 워크플로를 검증하세요.

이 페이지의 evidence를 실제 repository 하나에 적용하세요. “병합 전에 SQL 인젝션 탐지.”에서 어떤 finding이 생성되는지, 제안된 다음 단계를 재현할 수 있는지, local scan·report·agent·CI를 어디까지 확장해야 하는지 확인하세요.