|
http://www.hackerschool.org/HS_Boards/zboard.php?AllArticle=true&no=38 [복사]
Now, um.. For the past couple of years have been doing a code review for a lot of large code bases.
지난 몇 년 동안 방대한 양의 코드들에 대한 코드 리뷰를 해왔습니다.
And initially when I started uh.. doing code review
그리고 제가 처음으로 코드 리뷰를 하기 시작했을 때
it was pretty difficult trying to figure out everything like I had 60,000 ~ 70,000 lines of code.
6만~7만 줄의 코드를 모두 분석하는 것이 꽤나 힘들었습니다.
I had to review that code, trying find defects and it's really difficult for any one person or single team to go
전 그 6만줄짜리 코드에 대한 리뷰를 해야했고, 코드 내에서 결함을 찾으려고 했으나.. 그것은 한 사람이나 팀에게 매우 어려운 일이었습니다.
and review code without communicating and following through every sizngle step.
그리고 서로간의 대화와 공유 없이 코드 한줄 한줄을 따라다니며 분석을 했었습니다.
So, *** pass two years are so it ah... with help of few friends of mine with a my ex-company that I used to work for became up with some part of methodology.
2년이 지나고.. 예전에 일했던 회사에서 만난 몇몇 친구들의 도움을 받아 몇 가지 방법들을 찾아 나섰습니다.
Later on... last year, I think a microsoft started pushing threat analysis quite a bit,
그 이후.. 작년, 전 MS가 위협 분석에 대해 꽤 많은 지원을 시작했다고 생각합니다.
I look into that and liked their ideas as well,
저는 MS의 방법에 대해 조사를 했고, 아이디어가 괜찮다고 생각했습니다.
so I try come up with a some more different techniques of reviewing large source code bases.
그리고 저는 대량의 소스코드를 리뷰할 수 있는 저만의 다른 테크닉을 연구하기 시작했습니다.
And today I'm going to try focus this stock on that particular topic.
그리고 저는 오늘 이 주제에 대에 초점을 맞추려 합니다.
Basically, how do go about reviewing large code basis doing source code review and doing focus source code review to get most effective result.
기본적으로, 방대한 양의 소스 코드를 기준으로 분석을 할 때, 조금 더 효율적인 결과를 얻기위해 어떻게 집중하면 될까요?
um.. Defense in depth today
오늘날의 철저한 방어(보안)
We have firewalls, this is a big feature i guess,
우리는 방화벽을 사용하고, 이건 아주 중요한 기능입니다.
we have Firewalls, we have our DMZ, Host Assessment
우리는 방화벽을 사용하고, DMZ와 Host Assesment도 사용합니다.
We have typical Hardened Builds, Vulnerability Scanning but now this Code Review is becoming more and more popular
우리는 일반적으로 hardened build와 취약점 스캐너를 가지고 있지만, 요즘엔 소스 코드 리뷰가 점점 더 각광을 받고 있습니다.
a lot of companies want you to not just come and do web pentest
큰 회사들은 당신이 그냥 와서 웹해킹만 주구장창 하다 가기를 원하지 않습니다.
if there product company, not just do black box testing but also look at code review.
제품을 판매하는 회사라면 블랙 박스 테스팅과 코드 리뷰까지 전부 다 해주기를 원할 겁니다.
and.. How do we go about doing that code review?
그렇다면.. 코드 검토는 어떻게 해야할까요?
So this is the six points methodology
여기에 나열한 것이, 코드 검토 방법의 6가지 방법론입니다.
Start with Threat Model we'll talk about Threat Modeling
위협 모델부터 얘기하겠습니다. 위협 모델링을 말하는 것입니다.
basically uh.. trying to get data flow diagram of the entire application,
기본적으로는 전체 프로그램 흐름의 다이어그램을 얻어내는 과정을 말합니다.
and trying to figure out all the major entry points,
그리고 모든 entry point, 즉 진입점들을 분석합니다.
are all the major warns for someone's going to access something,
누군가가 어딘가에 접근하고자할 때 중요한 경고를 합니다.
and trying to see if there are vulnerabilities are that could be threat at a particularly point
특정 상황에서 위협이 될 수 있을만한 취약점이 있는지 찾아볼 수 있습니다.
like for web application, if like google the biggest threat point might be at the search, the search field itself
예를들어 웹 application의 경우, 이를테면 구글의 경우에 가장 큰 thread point는 검색 필드 그 자체가 될 수 있습니다.
if there hardened *** put their set the filter properly there would be no problems.
만약 사용자 입력에 대한 필터링를 올바르게 넣었다면 이부분에는 문제가 없을 것입니다.
are something among those lines, so we will talk about every single major entry point
이 것들을 보면서 각각의 모든 중요한 진입점에 대해 설명하겠습니다.
what are the different techniques we can go about doing that.
우리의 방식에 어떤 차이가 있는지도 설명하겠습니다.
uh.. The second step typically is do cursory Code Review.
일반적인 두번째 단계는 간단하게 한번 해보는 코드 리뷰입니다.
The reason for that is that every single person in world in doing a code review
이 것을 하는 이유는 세상의 모든 사람들이 코드 리뷰를 하기 때문입니다.
should understand how the entire application is written
이 것을 통해 전체 프로그램이 어떻게 작성되어 있는지를 이해햐야 합니다.
have common place where you have all your variable store
변수는 어디에 저장되어 있는지,
have common place where you have all your common note store
주석은 어떻게 작성되어 있는지,
so that when initially you're reviewing it you are understanding the mind set of programmer.
이처럼 기본적인 소스 코드 리뷰를 하면서 프로그래머의 생각을 이해할 수 있습니다.
The goal is to think like what the programmer was trying to do over there.
최종 목표는 프로그래머가 고민했던 것처럼 똑같이 생각하는 것입니다.
You're not going to go to depth you just see what exactly happening from variables' point of view in access.
너무 깊게 들어갈 필요는 없고, 단지 접근 관점에서 정확히 무엇이 일어났는지만 알면 됩니다.
Then you going to separation of code will talk about couple of meter
그 다음엔 코드를 분할합니다.
there's stander meter that microsoft come up with
MS가 제시한 표준 meter가 있습니다.
and then there's meter that 엠플로포우징 application architecture trying to be a value 투들 *** difference seperations how do you give value to it
또 다른 기준으로 나누는 방법
how do you figure out what exactly would give you more benefit to focus your time to was.
과연 어떤 방법이 여러분께 더 큰 이득을 줄지 어떻게 알 수 있을까요?
Then we will talk about maintaining code notes with reviewer name.
다음으로 우리는 리뷰어의 이름을 주석으로 달아 관리를 하는 것에 대해 얘기합니다.
This is very important
이 것은 굉장히 중요합니다.
simply because reviewer A might be reviewing a bunch of code
왜냐면 만약 리뷰어 A가 얼마만큼의 코드를 리뷰했다고 해봅시다.
and he will understand it he puts notes down
그는 코드를 이해했고, 주석을 달아 놓습니다.
uh.. reviewer B is could also accessing the same function
그 다음에 리뷰어 B가 같은 코드에 접근하게 될 수 있습니다.
he doesn't have to *** spend time trying to understand function call again.
그럼 그는 해당 코드를 이해하려고 시간을 낭비하지 않아도 됩니다.
so It is good idea to have reviewer note and reviewer names
그래서 리뷰어가 주석과 이름을 남기는 것은 좋은 아이디어이고,
so also little they what we end up doing giving customers just graph for that particular name
특정 이름의 grath를 고객에게 주는 것으로 마무리를 합니다.
and *** you don't have to maintain multiple notes ***
여러개의 주석을 관리할 필요는 없습니다.
더 이상의 개선사항이 없다면 이정도 선에서 종료하겠습니다. ^.^
|
Hit : 2000 Date : 2011/05/16 04:58
|
97, 
1/4 
멍멍
