자신이 해킹 할 수있는 것을 해제해야합니까?

프로그램을 만든 사람은 아마도 보안 취약점과 잠재적 인 해킹을 알고있는 사람보다 나은 위치에있을 것입니다. 작성한 시스템의 취약점을 알고 있다면 출시 전에 보안을 강화한 표시를 추가해야합니까, 아니면 보안 격차의 심각성을 판단하기 위해 경우에 따라 평가해야합니까?

나는 그것이 사례별로 수행되어야한다고 말하고 싶습니다. 당신은 저자이며 많은 구멍 을 알고 있습니다. 일부 취약점은 사용자에게만 알려질 수 있습니다. 물론 이는 악용 될 경우 답변하기 어려운 질문이있을 수 있으므로 가능한 경우 이러한 취약점을 줄이는 것이 좋습니다. 누군가가 블랙 박스 시스템으로 쉽게 해킹 할 수 있다면 더 중요합니다.

나는 상황에 두 번 불행한 경험을했습니다. 두 경우 모두 비즈니스는 매우 민감한 데이터 로 심각한 보안 문제가있는 제품을 출시했습니다 .

두 가지 경우 모두 비즈니스가 위험을 인식하도록 최선을 다했지만 최선을 다하고 있었지만

당신이 할 수있는 유일한 일은 가능한 한 큰 소리로 * (그리고 전문적으로) 항의하는 것 입니다. 관련 이메일을 PDF로 인쇄하여 파일을 집에 보관하거나 개인 이메일 주소를 숨기십시오. 이것은 불가피하게 나쁜 일이 발생할 때 유일한 해결책입니다.

경영진이 기술적 인 조언에 대해 당신을 존중하고, 그 점을 고려하지만 불행히도 의사 결정자가 하루를 끝낸 사람을 존중해야합니다. 잘못된 비즈니스 결정은 매일 이루어집니다.

편집 : jasonk는 "집 주소를 매우 조심하십시오"라고 언급했으며 매우 동의합니다. 회사 정책을 위반하지 말고 보안 취약점을 기존보다 더 많이 공개 할 위험이 있습니다.

나는 그 반대의 주장을 펼쳤습니다. 제작자라면 종종 코드에 너무 가까워 취약점을 볼 수 없습니다.

취약점에 대해 알고 있거나 알고 있다면 다른 버그와 비슷합니다. 평가하고 우선 순위를 정한 다음 수정하십시오.

그 해답은 악의적 인 해커가 시스템을 손상 시켰을 때 발생할 수있는 피해 정도에 달려 있다고 생각합니다. 분명히 토목 기사는 선의의 양심에서 안전하지 않은 다리의 설계를 승인 할 수 없었습니다. 이러한 다리의 건설은 부상이나 사망을 초래할 수 있습니다. 엔지니어가 의도적으로이 작업을 수행하는 것도 불법이지만 소프트웨어 엔지니어 (적어도 미국에서는)가 동일한 방식으로 법적 구속력이 없다는 사실은 결함이있는 시스템에 맞서야하는 전문적인 의무를 배제하지 않습니다. 불행히도 회사에서 소프트웨어를 출시하기 위해 서명이 필요하지 않을 수 있습니다.

작업중인 시스템의 정확한 특성을 지정하지 않았습니다. 의료 기록, 은행 업무, 항공 교통 관제 또는 기타 중요한 인프라와 관련이 있다면 릴리스 전에 가능한 최고 수준의 보안을 주장하는 것이 정당하다고 말하고 싶습니다.

예, 릴리스가 끝나기 전에 수정해야합니다. 해커의 독창성을 과소 평가하지 마십시오. 뒷문이 활짝 열려있는 상태에서 일주일 동안 휴가를 하시겠습니까? 당신의 변명은

"오 뒷면에 있고 거리를 직접 향하지 않습니다.

아마 아닙니다.

그러나 요즘은 보안 문제와 관련하여 잠재적으로 큰 책임 문제보다 가장 신성한 출시 날짜가 얼마나 중요한지에 대한 실마리없는 PM으로 이해합니다. 이 경우에주의를 기울여 문제를 기록하고 문제가 잘 문서화되고 잘 알려져 있는지 확인하고 위험을 명확하게 설명하고 PM이 무엇을해야할지 결정하도록하십시오.

PM이 잘못된 결정을 내리고이를 무시하고 일정에 따라 석방하기로 결정한 경우, 호루라기를 날려서 책임을지게됩니다.

그렇지 않으면 이것을 찾아서 스스로 지키고 어떤 일이 발생하면 결과에 대해 개인적으로 책임을 질 수 있습니다.

선택은 당신입니다.