MSN Live Messenger :
Rethinking Application Security에서 인상적인 구절에 대해 몇 마디.
요즘 CI 기반으로 일을 하면 할 수록 굳이 보안 문제(Security)가 아니더라도 프로젝트 초기에 팀 작업에 통합하고 지속적으로 유지하면 좋다는 확신이 선다. 비슷한 맥락의 글이 또 있다.
아래 글은 많은 경우 개발팀이 고객을 설득시켜야 하는 이유를 이야기하고 있다.
대부분의 고객은 특정 단위 시스템 혹은 모듈 개발이 끝나면 더 이상 해당 부분은 작업이 없을 것으로 기대한다. 하지만, 그 안에서 충분한 시간을 가지고 반복작업을 할 여유가 없었다면 기능 구현을 완료했더라도 구조적인 개선이나 품질향상을 위한 시간이 또 필요하기 마련이다. 실로 엄청난 반복의 위력을 이해하지 못하기에 더욱 그러하다.
그리고 매우 공감하는 이야기. 책으로는 해당 내용을 읽고 '안다'고 하면서 자신의 코드나 모델에는 반영하지 못하는 수많은 사람들을 현장에서 볼 수 있었다. 오히려 말과 산출물의 품질이 같은 경우는 일부 고수들 뿐이다.
지난 글 보기>
2007년 버전: 반복의 필요성:당연하지만 행하기 힘든 일
2006년 버전: 반복(Iteration)의 어려움
Discovering security problems early in the development cycle is only the first step toward creating more secure and reliable applications, says Parasoft's Wayne Ariola in an interview with Artima. For developers to work effectively in a security-conscious environment, addressing security-related coding issues must be integrated in developers' daily workflow
요즘 CI 기반으로 일을 하면 할 수록 굳이 보안 문제(Security)가 아니더라도 프로젝트 초기에 팀 작업에 통합하고 지속적으로 유지하면 좋다는 확신이 선다. 비슷한 맥락의 글이 또 있다.
Agile development practices have promoted the idea of continuous testing and defect detection. Not waiting for a separate Q&A cycle to detect errors late in the development cycle makes errors easier and cheaper to address. That's especially true of coding defects that can result in security violations.
아래 글은 많은 경우 개발팀이 고객을 설득시켜야 하는 이유를 이야기하고 있다.
Developers generally want to do the right thing with regard to security, but there is always a communication gap between management and the development team. Management may wish to focus on the functionality and making a deadline, and may not be that cognizant of the security implications of the software that's being developed and ultimately released. Developers, on the other hand, may know about potential security problems, but they seldom have the opportunity to communicate that to their managers, and especially to communicate that regularly.
대부분의 고객은 특정 단위 시스템 혹은 모듈 개발이 끝나면 더 이상 해당 부분은 작업이 없을 것으로 기대한다. 하지만, 그 안에서 충분한 시간을 가지고 반복작업을 할 여유가 없었다면 기능 구현을 완료했더라도 구조적인 개선이나 품질향상을 위한 시간이 또 필요하기 마련이다. 실로 엄청난 반복의 위력을 이해하지 못하기에 더욱 그러하다.
그리고 매우 공감하는 이야기. 책으로는 해당 내용을 읽고 '안다'고 하면서 자신의 코드나 모델에는 반영하지 못하는 수많은 사람들을 현장에서 볼 수 있었다. 오히려 말과 산출물의 품질이 같은 경우는 일부 고수들 뿐이다.
By the same token, developers may also not have many opportunities to learn about the security implications of their code. While many developers know about the basics of security, it's not easy to relate those abstract concepts to the actual code they're working on. Code reviews afford that opportunity, but those may not happen early enough in a project where remediation of the security-related problems can be done.
지난 글 보기>
2007년 버전: 반복의 필요성:당연하지만 행하기 힘든 일
2006년 버전: 반복(Iteration)의 어려움
이올린에 북마크하기
이올린에 추천하기
