|
http://www.hackerschool.org/HS_Boards/zboard.php?AllArticle=true&no=37 [복사]
저희 집에 있는 서버인데 가끔 예상치 못한 이유로 뻗곤 합니다 ㅠ.ㅠ
마지막에 작업 중이던 파트1을 복사해서 올립니다.
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 picture i guess,
우리는 방화벽을 사용하고, 사진이 너무 크네요,
we have Firewalls, we have our DMZ, Host Assessment
우리는 방화벽을 사용하고, DMZ와 Host Assesment도 사용합니다.
We have difficult Hardened Builds, Vulnerability Scanning but now this Code Review is becoming more and more popular
우리는 좋은 취약점 스캐너를 가지고 있지만, 요즘엔 소스 코드 리뷰가 점점 더 각광을 받고 있습니다.
a lot of company want you to not just come and do web pentest it
큰 회사들은 당신이 그냥 와서 웹해킹만 주구장창 하다 가기를 원하지 않습니다.
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 flood diagram of the entire application,
기본적으로는 전체 프로그램의 다이어그램을 얻어내는 과정을 말합니다.
and trying to figure out all the major entry points,
그리고 모든 entry point, 즉 진입점들을 분석합니다.
application 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.
우리의 방식에 어떤 차이가 있는지도 설명하겠습니다.
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 (please) where you have (all your variable) (store) have common please 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 wonder programer was trying to do all there.
You not going to go to depth you just see what exactly happening from variables' point of view **.
Then you going to separation of code will talk about couple of (meter) (there's) stander (meter) that microsoft come up with and then
there's (meter) 엠플로포우징 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 (dying) 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 and he will understand it he puts notes down
reviewer B is could also accessing the same function 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 also little (they) what we (end up) doing giving customers just graph for that
particular name and *** you don't have to maintain multiple notes ***
|
Hit : 2069 Date : 2011/05/16 10:43
|
97, 
1/4 
멍멍
