소프트웨어 취약성

컴퓨터 프로그래밍과 소프트웨어 공학에서, 소프트웨어 적합성은 신뢰할 수 있는 것처럼 보일 수도 있지만, 특이한 데이터로 제시되거나 사소한 방식으로 변경될 때 실제로 심하게 실패하는 오래된 소프트웨어를 고치는 데 있어 증가하는 어려움이다.그 구절은 금속공장에서 유사성에서 온 것이다.

원인들

소프트웨어가 새롭다면, 그것은 매우 유순하다; 그것은 실행자들이 원하는 것이 무엇이든 되도록 형성될 수 있다.그러나 주어진 프로젝트의 소프트웨어가 점점 더 커지고, 소프트웨어에 대한 오랜 경험을 가진 사용자들의 더 큰 기반을 개발하면, 그것은 점점 덜 순조로워진다.작업강화시킨 금속처럼 소프트웨어는 유산체계가 되어 부서지기 쉽고 시스템 전체를 파쇄하지 않고는 쉽게 유지될 수 없다.

소프트웨어의 취약성은 입력 데이터의 전체 범위에 대해 잘 작동하지 않는 알고리즘에 의해 야기될 수 있다.좋은 예로는 0으로 나누기를 허용하는 알고리즘이나, 적합된 데이터를 넘어 외삽하는 데 사용되는 곡선 적합 방정식이 있다.또 다른 취약성의 원인은 값을 제한하는 데이터 구조의 사용이다.이것은 1990년대 후반에 사람들이 그들의 소프트웨어가 2자리 숫자만 입력할 수 있다는 것을 깨달았을 때 흔히 볼 수 있었다; 이것은 2000년 이전에 엄청난 양의 부서지기 쉬운 소프트웨어를 갑자기 업데이트하게 만들었다.또 다른 공통적으로 접하는 쾌락의 형태는 잘못된 가정을 하는 그래픽 사용자 인터페이스에 있다.예를 들어, 사용자는 낮은 해상도의 디스플레이에서 실행 중일 수 있으며, 소프트웨어는 디스플레이에 맞추기 위해 창을 너무 크게 열 것이다.또 다른 일반적인 문제는 사용자가 기본값이 아닌 색 구성표를 사용하여 텍스트를 배경과 동일한 색상으로 렌더링하거나 사용자가 기본값이 아닌 다른 글꼴을 사용할 때 나타나는데, 이는 허용된 공간에 맞지 않고 지시사항과 라벨을 잘라낸다.

아주 흔히 낡은 코드 베이스는 그냥 버려지고 완전히 새로운 시스템(기존 시스템의 많은 부담에서 벗어나려는 의도)이 새로 만들어지지만, 이것은 비용이 많이 들고 시간이 많이 걸리는 과정이 될 수 있다.

소프트웨어 적합성 이면에 있는 몇 가지 예와 이유:

• 사용자들은 비교적 일정한 사용자 인터페이스를 기대한다. 일단 기능이 구현되어 사용자에게 노출되면, 기능이 잘 설계되지 않았거나 기능이 더 진행되지 않더라도 해당 기능에 대한 주요 변경을 수용하도록 설득하는 것은 매우 어렵다.
• 많은 문서들이 현재의 행동을 설명할 수 있으며 변경 비용이 많이 들 것이다.또한 기존 설명서의 모든 사본을 회수하는 것은 본질적으로 불가능하기 때문에 사용자들은 계속해서 구식 설명서를 참조할 가능성이 높다.
• 원래 구현자(사물이 실제로 어떻게 작동하는지 알고 있는 사람)는 소프트웨어의 내부 작업에 대한 문서화를 충분히 남겨두지 않았다.많은 작은 구현 세부 사항들은 설계팀의 구두 전통을 통해서만 이해되었고, 소프트웨어 고고학의 부지런하고 값비싼 응용을 통해 일부 사항을 재발견할 수 있지만, 이러한 세부 사항들은 결국 돌이킬 수 없이 상실된다.
• 패치는 아마도 수년간 발행되어 소프트웨어의 동작을 미묘하게 변화시켰을 것이다.많은 경우, 이러한 패치는 발급된 명백한 오류를 수정하는 동시에 다른, 더 미묘한 고장을 시스템에 도입한다.회귀 테스트에 의해 감지되지 않는 경우, 이러한 미묘한 고장은 시스템의 후속 변경을 더욱 어렵게 한다.
• 보다 미묘한 형태의 취미가 인공지능 시스템에서 흔히 발생한다.이러한 시스템은 입력 데이터에 대한 유의미한 가정에 의존하는 경우가 많다.이러한 가정이 충족되지 않을 경우(그리고 명시되지 않을 수 있기 때문에, 이는 쉽게 발생할 수 있음) 시스템이 완전히 예측할 수 없는 방식으로 반응할 것이다.
• 요소 의존성이 너무 경직되면 시스템도 취약해질 수 있다.이것의 한 예는 의존성의 새로운 버전으로 전환하는 어려움에서 볼 수 있다.한 구성 요소가 다른 구성 요소가 주어진 값의 범위만 출력하고 그 범위가 변경될 것으로 예상할 때, 그것은 빌딩이나 런타임에 시스템에 오류를 발생시킬 수 있다.
• 시스템 개발 라이프사이클(SDLC)의 개발 또는 구현 단계에 있는 시스템보다 시스템이 유지보수 단계에 있을 때 변경을 지원할 수 있는 기술 자원이 더 적다.

참고 항목

• 브레이틀 시스템
• 소프트웨어 엔트로피
• 소프트웨어 썩음
• 견고성(컴퓨터 과학)

참조

• Robert E. Filman; Tzilla Elrad; Siobhán Clarke; Mehmet Aksit (2004). Aspect-Oriented Dependency Management. Addison Wesley Professional. ISBN 0-321-21976-7.^{[영구적 데드링크]}
• Anastasios Manessis, Adrian Hilton, Phil McLauchlan and Phil Palmer (2000). "A Statistical Geometric Framework for Reconstruction of Scene Models" (PDF). British Machine Vision Conference.{{cite journal}}: CS1 maint : 복수이름 : 작성자 목록(링크)
• Virginia Postrel (1999). "Power fantasies: the strange appeal of the Y2K bug – Year 2000 transition problem". Reason. Archived from the original on 2005-09-10. Retrieved 2008-07-25.