예비 보안 점검 결과 — ContextualWisdomLab/appguardrail #132

예비 보안 점검 결과 — ContextualWisdomLab/appguardrail

공개 GitHub 리포지토리 기준의 정적 예비 점검입니다. 로컬 클론, 테스트 실행, 전체 의존성 트리 분석, 실제 패키지 배포물 검증은 수행하지 않았으므로 “감사 완료”가 아니라 우선 조치가 필요한 보안 리뷰 초안으로 보는 것이 적절합니다.

요약

appguardrail은 AI로 만든 앱을 대상으로 보안 가드레일, 스캔, 리뷰, 모니터링, 수정 지원을 제공하는 CLI/워크플로 중심 도구로 보입니다. README는 Python 3.9 이상, pip install appguardrail, appguardrail scan, Trivy/CodeGraph 연동, 시크릿·의존성·인증 누락·Firebase/Supabase/CORS/Stripe 관련 패턴 탐지를 설명하고 있습니다. pyproject.toml 기준 런타임 Python 의존성은 비어 있고, 콘솔 엔트리포인트는 scanner.cli.appguardrail:main입니다. (GitHub)

가장 우선적으로 볼 이슈는 네이티브 시크릿 탐지 결과가 매칭된 코드 라인을 그대로 출력할 수 있는 점입니다. 이 도구가 CI에서 실행될 경우 실제 시크릿이 로그나 아티팩트에 남을 가능성이 있어, 보안 도구 자체의 목적과 충돌합니다. 반면 Trivy 연동 결과에서는 시크릿 값을 억제하는 처리도 보여, 네이티브 스캐너에도 동일한 정책을 적용하는 것이 타당합니다. (GitHub)

적용 기준

이번 예비 점검에는 다음 기준을 적용했습니다.

개발자 티켓 초안

Ticket 1 — Secret scan output redaction

Severity: High
Type: CWE-532 / CWE-200
Affected area: scanner/cli/appguardrail.py, scanner/rules/secrets.yml

Description:
Native secret detection can print the matched source line as a finding snippet. If real credentials are present, scan output may expose them in terminal or CI logs.

Acceptance criteria:

1. Secret-related findings never print the matched secret value.

2. Default output shows file, line, rule ID, severity, and redacted snippet only.

3. Unit tests confirm fake Stripe/OpenAI/JWT/DB URL values do not appear in stdout/stderr.

4. Trivy secret suppression behavior and native scanner behavior are consistent.

Ticket 2 — Harden AI review workflow permissions

Severity: Medium
Type: CI/CD hardening, OWASP CICD-SEC-5 / CICD-SEC-6

Description:
Review workflows use privileged contexts and external runtime tools. Existing mitigations are present, but permissions and third-party package execution should be further minimized.

Acceptance criteria:

1. Remove id-token: write unless an explicit OIDC trust relationship requires it.

2. Document why each permission is required.

3. Replace runtime npx -y installs with hash-locked or containerized tooling.

4. Add workflow linting and dependency review as required checks.

Ticket 3 — Hash-lock release dependencies and generate SBOM

Severity: Medium
Type: Supply chain hardening, OWASP A03:2025

Description:
Release workflow uses pinned versions for build tooling but does not appear to enforce hash-based dependency integrity.

Acceptance criteria:

1. requirements-release.txt is generated with hashes.

2. CI uses pip install --require-hashes.

3. Release pipeline emits SBOM.

4. Release job runs OSV or pip-audit against resolved dependencies.

5. Published artifacts include provenance or attestations.

결론

이 리포지토리는 보안 목적의 도구답게 승인 범위 문서, 책임 있는 테스트 안내, CI 권한 제한, 액션 SHA 핀, PyPI OIDC 게시 등 긍정적인 통제가 이미 보입니다. 가장 먼저 고쳐야 할 부분은 시크릿 탐지 결과의 원문 출력 방지입니다. 그 다음은 AI/CI 워크플로의 권한·외부 도구·토큰 노출면 축소, 릴리스 의존성 무결성 강화, SBOM/CVE 자동 검증 순서가 적절합니다.

다음 단계는 승인된 범위에서 로컬 appguardrail scan, pip-audit, OSV-Scanner, SBOM 결과를 함께 대조해 CVE 후보를 확정하는 것입니다.

공개 GitHub 리포지토리 기준의 정적 예비 점검입니다. 로컬 클론, 테스트 실행, 전체 의존성 트리 분석, 실제 패키지 배포물 검증은 수행하지 않았으므로 “감사 완료”가 아니라 우선 조치가 필요한 보안 리뷰 초안으로 보는 것이 적절합니다.

요약

appguardrail은 AI로 만든 앱을 대상으로 보안 가드레일, 스캔, 리뷰, 모니터링, 수정 지원을 제공하는 CLI/워크플로 중심 도구로 보입니다. README는 Python 3.9 이상, pip install appguardrail, appguardrail scan, Trivy/CodeGraph 연동, 시크릿·의존성·인증 누락·Firebase/Supabase/CORS/Stripe 관련 패턴 탐지를 설명하고 있습니다. pyproject.toml 기준 런타임 Python 의존성은 비어 있고, 콘솔 엔트리포인트는 scanner.cli.appguardrail:main입니다. ([GitHub]1)

가장 우선적으로 볼 이슈는 네이티브 시크릿 탐지 결과가 매칭된 코드 라인을 그대로 출력할 수 있는 점입니다. 이 도구가 CI에서 실행될 경우 실제 시크릿이 로그나 아티팩트에 남을 가능성이 있어, 보안 도구 자체의 목적과 충돌합니다. 반면 Trivy 연동 결과에서는 시크릿 값을 억제하는 처리도 보여, 네이티브 스캐너에도 동일한 정책을 적용하는 것이 타당합니다. ([GitHub]2)

적용 기준

이번 예비 점검에는 다음 기준을 적용했습니다.

주요 발견 사항

AG-01 상세: 시크릿 로그 노출

위험

현재 구조에서는 예를 들어 .env 또는 설정 파일에 실제 Stripe/OpenAI/JWT/DB URL이 있을 때, 스캐너가 이를 탐지하면서 해당 라인을 Code: 출력에 포함할 수 있습니다. 보안 도구가 CI에서 실행되면 GitHub Actions 로그, PR 코멘트, 저장된 아티팩트, 외부 로그 수집기로 시크릿이 유출될 수 있습니다. secrets.yml은 여러 시크릿 패턴을 CRITICAL/HIGH로 정의하고 있고, 출력 함수는 매칭 라인 snippet을 보여주는 구조입니다. (GitHub)

권장 수정 방향

시크릿 탐지 룰은 “파일명, 라인 번호, 룰 ID, 심각도, 설명”만 출력하고, 매칭 값은 항상 숨기는 방식이 안전합니다.

예시 정책:

Before:
Code: STRIPE_SECRET_KEY=sk_live_xxxxxxxxx

After:
Code: STRIPE_SECRET_KEY=[REDACTED]

구현 방향은 다음과 같습니다.

SENSITIVE_RULE_TOKENS = (
    "secret",
    "password",
    "token",
    "jwt",
    "database-url",
    "db-url",
    "stripe",
    "openai",
    "supabase-service-role",
)

def is_sensitive_rule(rule_id: str) -> bool:
    lowered = rule_id.lower()
    return any(token in lowered for token in SENSITIVE_RULE_TOKENS)

def safe_snippet(rule_id: str, snippet: str) -> str:
    if is_sensitive_rule(rule_id):
        return "[REDACTED: sensitive match suppressed]"
    return snippet

더 나은 방식은 “라인 전체 삭제”보다 매칭된 값만 마스킹하는 것입니다. 다만 첫 패치는 보수적으로 전체 snippet을 숨기는 편이 안전합니다.

검증 방법

승인된 로컬 테스트 디렉터리에서만 다음 성격의 테스트를 추가합니다.

mkdir -p /tmp/appguardrail-redaction-test
cat > /tmp/appguardrail-redaction-test/.env <<'EOF'
OPENAI_API_KEY=sk-test-redaction-example-not-real
JWT_SECRET=example-jwt-secret-not-real
EOF

appguardrail scan /tmp/appguardrail-redaction-test 2>&1 | tee /tmp/ag.out

# 실패 조건: 원문 시크릿이 출력에 포함됨
grep -E 'sk-test-redaction-example|example-jwt-secret' /tmp/ag.out && exit 1

# 성공 조건: 룰은 탐지되지만 값은 마스킹됨
grep -E 'REDACTED|sensitive match suppressed' /tmp/ag.out

CI/CD 및 AI 리뷰 워크플로 평가

opencode-review.yml은 pull_request, pull_request_target, workflow_dispatch를 모두 다루며, same-repo 조건, 신뢰 워크플로 체크아웃, persist-credentials: false, OpenCode CLI SHA256 검증, 에이전트 권한 deny 설정 등 여러 완화책을 갖고 있습니다. 이 점은 긍정적입니다. ([GitHub]6)

다만 pull_request_target은 설계상 base repository 권한·시크릿 접근과 연결될 수 있어, PR head 코드를 실행하거나 그 입력이 명령 실행에 영향을 주면 위험이 커집니다. GitHub는 pull_request_target에서 신뢰되지 않은 코드를 체크아웃·실행하는 패턴을 특히 경고하며, GITHUB_TOKEN은 워크플로 내 액션이 접근할 수 있으므로 최소 권한으로 제한하라고 안내합니다. ([The GitHub Blog]10)

권장 우선순위는 다음과 같습니다.

CVE 후보 확인

공개 파일에 보이는 직접 핀 기준의 제한적 확인입니다. 전체 전이 의존성, 실제 설치 환경, lockfile, SBOM이 없으므로 최종 판정은 아닙니다.

권고 조치 우선순위

개발자 티켓 초안

Ticket 1 — Secret scan output redaction

Severity: High
Type: CWE-532 / CWE-200
Affected area: scanner/cli/appguardrail.py, scanner/rules/secrets.yml

Description:
Native secret detection can print the matched source line as a finding snippet. If real credentials are present, scan output may expose them in terminal or CI logs.

Acceptance criteria:

1. Secret-related findings never print the matched secret value.
2. Default output shows file, line, rule ID, severity, and redacted snippet only.
3. Unit tests confirm fake Stripe/OpenAI/JWT/DB URL values do not appear in stdout/stderr.
4. Trivy secret suppression behavior and native scanner behavior are consistent.

Ticket 2 — Harden AI review workflow permissions

Severity: Medium
Type: CI/CD hardening, OWASP CICD-SEC-5 / CICD-SEC-6

Description:
Review workflows use privileged contexts and external runtime tools. Existing mitigations are present, but permissions and third-party package execution should be further minimized.

Acceptance criteria:

1. Remove id-token: write unless an explicit OIDC trust relationship requires it.
2. Document why each permission is required.
3. Replace runtime npx -y installs with hash-locked or containerized tooling.
4. Add workflow linting and dependency review as required checks.

Ticket 3 — Hash-lock release dependencies and generate SBOM

Severity: Medium
Type: Supply chain hardening, OWASP A03:2025

Description:
Release workflow uses pinned versions for build tooling but does not appear to enforce hash-based dependency integrity.

Acceptance criteria:

1. requirements-release.txt is generated with hashes.
2. CI uses pip install --require-hashes.
3. Release pipeline emits SBOM.
4. Release job runs OSV or pip-audit against resolved dependencies.
5. Published artifacts include provenance or attestations.

결론

이 리포지토리는 보안 목적의 도구답게 승인 범위 문서, 책임 있는 테스트 안내, CI 권한 제한, 액션 SHA 핀, PyPI OIDC 게시 등 긍정적인 통제가 이미 보입니다. 가장 먼저 고쳐야 할 부분은 시크릿 탐지 결과의 원문 출력 방지입니다. 그 다음은 AI/CI 워크플로의 권한·외부 도구·토큰 노출면 축소, 릴리스 의존성 무결성 강화, SBOM/CVE 자동 검증 순서가 적절합니다.

다음 단계는 승인된 범위에서 로컬 appguardrail scan, pip-audit, OSV-Scanner, SBOM 결과를 함께 대조해 CVE 후보를 확정하는 것입니다.