티켓 연동

티켓을 낼 만한 일이 생기면 포털이 지정한 주소로 사건을 보냅니다. 그것을 받아 조직이 쓰는 트래커의 티켓으로 만드는 것은 조직이 작성한 어댑터의 몫입니다.

기본은 꺼짐입니다. 주소를 지정하지 않으면 아무것도 호출하지 않습니다. 요청도, 큐에 넣는 작업도, 발송을 건너뛰었다는 로그도 없습니다.

왜 일반 웹훅인가

특정 트래커용 어댑터를 내장하지 않은 것은 빠뜨린 것이 아니라 결정입니다. 사건을 티켓으로 옮기는 방식은 조직마다 가장 크게 갈리고, 설정으로 담기 어려운 방식으로 갈립니다. 어느 프로젝트에 넣을지, 이슈 유형은 무엇인지, 필수 사용자 정의 필드가 무엇인지, 담당자를 누구로 둘지, 새로 만들지 기존 티켓을 갱신할지가 전부 다릅니다. 트래커 하나에 맞춘 어댑터는 한 조직에만 맞고 나머지 조직에는 "우리 것도 되겠지"라는 오해를 줍니다.

조직이 작성할 것은 크지 않습니다. JSON POST를 받아 트래커 API를 호출하는 엔드포인트 하나입니다.

설정

설정	뜻
TICKET_WEBHOOK_URL	보낼 주소. 비우면 꺼짐입니다.
TICKET_WEBHOOK_TOKEN	선택적 토큰. 비우면 없음이고, 주소 자체에 비밀이 들어 있는 형태라면 그것이 맞습니다.
TICKET_WEBHOOK_EVENTS	티켓을 낼 사건 종류, 쉼표로 구분. 비우면 전부입니다.

대개는 몇 가지만 지정합니다. 스캔 완료는 채팅 채널에 한 줄 남길 일이지 누군가 닫을 티켓을 만들 일은 아니고, 새 critical CVE나 검토 대기 컴포넌트는 대개 그렇습니다.

보내는 문서

{
  "version": 1,
  "event": "new_critical_cve",
  "occurred_at": "2026-08-20T09:12:44.128301+00:00",
  "source": "trusca",
  "context": {
    "cve_id": "CVE-2026-1234",
    "project_id": "3f1c…",
    "project_name": "payments-api",
    "severity": "CRITICAL"
  }
}

version은 필드의 뜻이 바뀌거나 사라질 때 올립니다. 필드가 늘어나는 것으로는 올리지 않으니, 어댑터는 모르는 키를 무시하도록 작성하십시오.

context는 포털이 만든 그대로 전달되고 키 구성은 사건 종류에 따라 다릅니다. 필요한 것만 읽고 나머지는 무시하면 새 사건 종류가 생겨도 어댑터를 고칠 일이 없습니다.

트래커가 응답하지 않을 때

본 흐름에는 영향이 없습니다. 전송은 별도 백그라운드 작업이 하고 사건을 만든 흐름은 기다리지 않습니다. 그래서 트래커가 느린 날이 스캔이 11분 걸리는 날이 되지 않고, 트래커가 죽은 날이 스캔이 실패하는 날이 되지 않습니다.

받는 쪽 응답	포털의 처리
2xx	완료
5xx·타임아웃·연결 거부	백오프를 두고 최대 5회 재시도
4xx	즉시 포기. 문서를 거부한 수신자는 10분 뒤에도 거부하고, 그 재시도만 상대 로그에 쌓입니다

전달하지 못한 사건은 로그를 남기고 버립니다. 그 사건이 가리키는 일 자체는 포털에 남아 있고 담당자는 그 일에 해당하는 화면에서 보게 됩니다. 티켓은 그 위에 얹는 편의이지 기록 자체가 아닙니다.

정상 동작 확인

1. TICKET_WEBHOOK_URL을 지정하지 않은 상태에서 critical 발견이 나오는 스캔을 돌리고, 받는 쪽에 아무 기록도 남지 않는지 확인합니다.

2. TICKET_WEBHOOK_URL을 요청 확인용 주소로 지정하고 같은 과정을 반복해, 위 형식의 POST가 한 번 도착하는지 확인합니다.

함께 보기

• 알림: 누가 소식을 받는지는 무엇이 티켓이 되는지와 별개의 질문입니다.