[EIP] 필기 1일차

in Study on EIP

시나공의 정처기 필기 대비 요약본을 하루하고도 한나절 정도 보고 필기를 치고 왔다. 순수 공부시간으로는 아마 10시간 정도였던 것 같다.
1과목(스프트웨어 설계) 같은 경우 배운 적 없었던 소프트웨어 공학이기에 시간이 조금 걸렸다. 물론 개념적으로나 경험적으로 얼추 알고 있는 지식들이었기 때문에 정리하는 과정이 가장 재밌긴 했다. 대략 3시간 정도 소요되었다.
2과목(소프트웨어 개발)부터 3과목(데이터베이스 활용)은 전공과목들(데이터구조, 데이터베이스)의 내용의 딱 절반 정도를 담고 있는 것 같았다. 모두 알고 있는 내용이지만 까먹거나 헷갈리는 것이 있을지도 모르니 정독하기로 했다. 두 과목을 합쳐서 4시간 정도 걸렸다.
4과목(프로그래밍 언어 활용)을 읽는 것은 시간 낭비에 가까웠다. 정말 기초적인 언어 문법 지식과 약간의 전공지식(컴퓨터구조, 네트워크)을 묻는 과목인데, 학부생 2학년 정도만 되어도 막힘 없이 읽어나갈 수 있을 듯했다. 너무 쉬워서 오히려 자꾸 집중이 깨졌다. 정독에 2시간 정도 소요되었다.
5과목(정보시스템 구축 관리)는 소프트웨어 공학과 컴퓨터 보안을 아주 약간씩 섞어 놓은 것 같았다. 그런데 그렇다고 그 두 과목을 얼마만큼 coverage하고 있느냐고 묻는다면 5%.. 정도겠다. 그냥 학부생으로서 자기 전공에 최소한의 관심만 가졌더라면 이미 다 주워들은, 체화한 지식들이다. 마찬가지로 정독에 1시간 정도 걸린 듯하다.

솔직히 필기본을 읽어보기 전까지만 해도 너무 늦게 시작했나 긴장되고, CBT도 몇번 돌려봐야겠다 싶었는데 정독 1회독을 마치니 긴장이 다 풀렸다. 이제 필기치러 가본다.

…갔다 왔다. 뭐랄까, 예상대로다. 무난하게 합격했다. 외외라면 대부분의 용어를 영어를 그대로 쓴다. 한국어로만 전공을 들은 친구라면, 그리고 나처럼 필기요약본조차 읽지 않고 갔다면 조금 당황스럽긴 했을 수도 있..나? 그래도 못 풀 정도는 아니다.
또한, 방법론이나 개발도구, 프로토콜, 프레임워크의 종류를 묻는 문제들이 꽤 있었다. 문제는 질문이나 선택지에 딸랑 영어 약어 하나만 던져준다는 것. 그렇다고 정리해서 외울 필요까지는 없고, 수많은 도구들을 귀찮다고 넘기진 말고 정독까진 해야한다는 말이다. 본인은 솔직히 소챕터마다 열몇개씩 있는 예시들을 다 읽지는 않았다. 그랬더니 기억이 희미해서 절반쯤은 틀린 듯한데, 그게 8~10문제 정도 될거다. 평균 10점씩 내려간 셈이다. 다만 정독만 하면 충분히 기억에 남으니 집중을 놓치지만 않으면 될 것 같다.

졸려서 말이 흐릿한데, 결론은 학부생이라면 공부안하고 가도 ‘필기는’ 충분히 안정적일 듯 하다. 이제 실기 공부를 해야겠다. 필기를 빨리 쳐서 실기 시작일까지 적어도 3개월은 남았으니, 일주일 단위로 나눠서 진도를 천천히 나가도 될 듯하다. 그런데 실기 난이도나 출제 범위도 아직 몰라서.. 다음주에 계획으로 돌아와야겠다!

Easy!!

Friend Class

in Study on OODP

Nested Class

Exception class

프로그램은 runtime problem을 마주치곤 한다. 존재하지 않는 파일에 접근이나, 메모리의 부족이 가장 자주 발생한다. 이러한 상황에 대처하는 강력하고 유연한 exception들을 c++은 지원한다.

[error-throw-object]:

[EIP] 필기 1일차

in Study on EIP

필기 시험 날짜는 2024년 5월 9일(목)이다. 너무 늦게 공부를 시작했나 싶긴 하지만, 남은 이틀 동안 최대한 빠르게 많이 훑어보고 시험장에 들어가보자. 공부 재료는 역시나 시나공이다. 오늘 처음 회원가입하고 써보는데 무료로 많은 자료와 기출문제들이 있어서 이틀 동안 소화하기 알맞을 것 같다.

목표는 1일차에 쉬운 1,2,3과목에 대해 개념 훑어보기를 끝내고 확인차 기출을 풀어보는 것이다. 2일차 목표는 4과목을 기출 3회 정도 돌려보고, 5과목은 정리하면서 이해하기. 기출도 2회 정도는 풀 수 있으면 좋겠다.

1. 소프트웨어 설계

그럼, 1과목부터 시작! 소프트웨어 공학은 아쉽게도 학부 과정에서 듣지 못해서 조금 시간이 걸릴 수도 있을 것 같다. 소프트웨어 공학은 소프트웨어의 위험(risk)를 관리하기 위해 연구된 학문을 말한다. 품질 및 생상성 향상을 위해 여러가지 방법론과 도구, 관리 기법들이 만들어졌다. 가장 기본적인 원칙은 지속적인 검증과 기록이다.

Time-Series Data

in Study on AI

시계열은 chrononlogical 순서에 따라 정량적으로 관찰된 집합이다. 다른 말로, 시간 순서로 배열된 데이터의 수열이다. 일정 시간 간격의 데이터의 순차열이다. 일반적으로 x축에 시간, y축에 관찰한 값으로 표현한다.

Time-Series Components

  • Trend : 긴 시간에 걸친 평균적 변화
  • Seasonal : 정해진 간격에 따라 나타나는 패턴으로 frequency라고도 불린다.
  • Cyclic : 고정되지 않은 간격에서 나타나는 패턴으로 보통 seasonal보다 길다.
  • Irregular

Time-Series Property

  • Stationary : 시간과 독립적으로 관찰되는 데이터
  • Non-stationary : 평균과 분산이 시간에 따라 변화하는 모델이다. differencing 기법을 사용해 Stationary로 변환할 수 있다.

Autocorrelation Function(ACF)

시계열 분석을 위해 사용되는 함수이다.

  • Correlation

  • lag-n correlation : 최신값과 n step 전의 값 간의 correlation을 계산

모든 n에 대한 lag-n를 도출하는 것이 ACF의 역할이다.

Basic Decomposition

Time-Series Data Prediction

Progress Report

in Project on ByCoBERT

ByCoBERT의 전신인 DexBERT는 애초에 class 단위 보안취약점 검출을 위한 도구였음. 이를 프로젝트 단위로 예측하도록 코드를 수정한 것이 현재의 ByCoBERT임. 수정한 이유는 보안 취약점 여부가 라벨링된 데이터셋을 직접 만드는 과정에서 프로젝트 단위로 밖에 라벨링하지 못했기 때문임. 그럼에도 ByCoBERT는 비록 작은 데이터셋이지만 OWASP의 class-level 보안 취약점 예측에서도 아래 그림처럼 무작위 이상의 예측 성능을 보였음.

따라서, class 단위로 취약점 여부를 라벨링한 충분히 큰 데이터셋을 확보한다면 유의미한 결과를 얻을 수 있을거라고 판단됨. 그러한 데이터셋을 확보하기 위해 2가지 방법을 고안함.

첫째, 기존에 사용된 600개 프로젝트의 데이터셋에 프로젝트 단위로 라벨링된 취약점을 class 단위로 다시 라벨링한다. 600개 프로젝트에는 총 300개의 취약한 프로젝트가 존재한다. 프로젝트 명과 버전을 담은 목록이 httpstest_300_300/vul300List.csv다. 그중 일부의 mvnrepo 링크를 담은 목록은 mvn-crawler/vulList.csv이다. 그 중 임의의 링크, https://mvnrepository.com/artifact/org.owasp.antisamy/antisamy/1.5.3로 들어가면 다음과 같은 화면이 뜬다.

이중 Direct vulnerabilities에 속한 CVE가 존재하는 class 들을 라벨링할 것이다. 저 CVE 중 아무 버튼을 클릭해 들어가면 아래와 같은 화면이 뜬다.

다시 한번 NVD 링크를 클릭해 들어가면 아래와 같이 뜬다.

이 CVE는 최근 발견된 CVE라서 어떻게 고쳐야하는지 해당 페이지에서는 확인하기 어렵다. 이런 경우에는 발품을 팔아야할 것 같은데, 어떤 class가 문제인지 어떻게 파악해야할지 방법을 찾고 있다. 이외에도 REJECT된 CVE 등 다른 예외들도 있어서 크롤링 이후 따로 확인해야할 CVE들이 많을 수 있겠다. 다른 CVE 예시로 들어가보겠다. 상기와 동일한 방식으로 CVE 링크를 타고 들어가니 아래와 같은 화면이 뜬다.

이제 아래 Reference 링크들 중에 특정한 패턴(~/github.com/~/commit/~)에 일치하는 링크를 찾아 들어간다.

어떤 파일이 수정되었는지 확인할 수 있다. 동명의 class 파일에 CVE가 존재했다고 라벨링한다. 위의 절차를 자동화한 툴을 만들면 비교적 빠르게 class 단위 라벨링을 마칠 수 있다. 코드를 짜고, 위에서 보인 몇몇 예외들을 발품 팔아 라벨링하고, 정리하는데 1주일 가량을 잡으면 될 것 같다. 크롤러의 설계는 다음과 같다. 1) 300개 프로젝트의 direct CVE를 목록화 2) 각 CVE에 대한 사이트로 이동: https://cve.mitre.org/cgi-bin/cvename.cgi?name={cve_id} 3) github 커밋 패턴의 url로 이동: ~/github.com/~/commit/~ 4) 수정된 파일 목록 크롤링: ~/~.java 5) 600개 프로젝트의 class 단위로 취약점 여부를 라벨링 6) 결과 파일: vul_project(project, version, cve_id, cve_cite), cve_related_class(cve_id, class_name, github_url), labeled_class_600(project, version, class, label)

두번째 방법은 Juliet의 class들을 활용하는 것이다. juliet에서 기존의 파일들을 clean과 vul로 분리한다고 가정했을 때, bad / good / goodB2G,goodG2B 버전의 파일들을 얻을 수 있다. good2들을 어떻게 배정해야할지는 고민된다. 한편, Juliet은 CWE를 기반으로 만들어져있다는 것도 고려해야한다.

6주(+3일) 가량의 시간이 주어지는데 어떻게 진도를 나아갈지 대강의 목표를 설정해보았다. 각 실험은 약 4일이 소요될 것이라고 가정한다.

  • 1주차 : class 단위 라벨링 및 문서작업
  • 2주차 : pretrain4ByCoBERT.py 토크나이징 알고리즘을 project 단위에서 class 단위로 수정 및 정상동작 확인
  • 3주차 : 실험1 / 실험2
  • 4주차 : 실험3 / 실험4
  • 5주차 : 실험5 / 실험6
  • 6주차 : 결과 정리 및 후속 연구를 위한 문서작업
  • 7주차 : video 및 발표 준비(DL_final)

6번 정도의 재실험 기회를 가지는 것이 목표이다. 어떤 조건들을 바꿔가며 실험하게 될지는 아직은 감이 잡히진 않는다. 그러나 바로 좋은 성과가 나올거라 기대하기보단, 충분한 여유를 두어 재실험할 시간을 마련하는 것이 좋을 것 같다.

Class Templates

in Study on OODP

Class template는 코드를 재사용하기 위한 또다른 수단이다. C++의 STL(Standard Template Library)는 valarray, vector, array와 같은 여러 temlate class들을 지원한다. 이렇게 type-independent한 형태로 코드를 작성하는 패러다임을 generic programming이라고 부른다.

Defining a Class Template

Class template의 정의는 function template과 유사하다. 개발자와 compiler가 찾기 쉬운(ex, header file) 곳에 정의할 필요가 있다.

Stack을 class template을 사용하여 구현해보자.

template <typename Type>    // Type : type parameter
// equivalent with
// template <class Type>
class Stack
{
private:
    enum {MAX = 10};    // constant specific to class
    Type items[MAX];    // holds stack items
    int top;            // index for top stack item
public:
    Stack();
    bool isempty();
    bool isfull();
    bool push(const Type& item);
    bool pop(Type& item);
};
template<typename Type>
Stack<Type>::Stack()
{
    top = 0;
}

여기서 type parameter(Type)은 매개변수처럼 원하는 type을 컴파일러에게 넘긴다. function template의 경우, 넘겨받은 값의 type에 맞게 맞춰지지만 class template은 type을 명시해줘야 한다.

Stack<int> kernels;     // create a stack of ints
Stack<string> colonels; // create a stack of string objects

template<class T> void simple(T t) { cout << t << ‘\n’; }
simple(2);      // generate void simple(int)
simple(“two”);  // generate void simple(const char*)

일단 stack이 특정한 type으로 생성이 된다면, 해당 type의 ordinary object로 사용할 수 있다.

Non-Type Arguments

Array temlate을 예시로 Non-Type argument를 어떻게 받을 수 있는지 살펴보겠다.

template <class T, int n>   // Type argument: T, argument: n
class ArrayTP
{
private:
    T ar[n];
public:
    ArrayTP() {}
    explicit ArrayTP(const T& v);
    virtual ~ArrayTP() {}
    virtual T& operator[](int i);
    virtual T operator[](int i) const;
};
template<class T, int n>
ArrayTP<T,n>::ArrayTP(const T& v)
{
    for(int i = 0; i < n; i++)
    ar[i] = v;
}

ArrayTP<double, 12> eggweights;

위 코드에서 컴파일러는 double eggweights[12]와 동일하게 대체한다. 이때, integer parameter(n)은 반드시 컴파일 타임에 결정되는 상수여야 한다. 상수이기만 한다면 integer type, enumeration type, reference, pointer 무엇이든 상관 없다. 그러나 altered value나 address를 받을 수는 없다(n++, &n). 이를 non-type 혹은 expression argument라고도 부른다.

Template Versatility

Using More Than One Type Parameter

Default Type Template Parameters

Explicit Specializations

template<class T> class Test
{
public:
    Test() { cout << "General template object\n"; }
};

template<> class Test<int>
{
public:
    Test() { cout << "Specialized template object for int\n"; }
};

int main()
{
    Test<int> a;    // Specialized template object for int
    Test<char> b;   // General template object
    Test<float> c;  // General template object
    return 0;
}

Partial Specialization

Member Templates

C++에서 class 안에 class를 정의할 수 있다. 마찬가지로, template class 안에도 template class와 template function을 정의할 수 있다.

template<typename T>
class A {
private:
    template<typename V>
    class B { ... };
    B<int> q;
    B<T> m;

    template<typename U> U func(U a, T b) { ... }
    // ...
};

Template Aliases

Questions?

Q1.
A1.

Q2.
A2.

[students]:

Overview

in Project on ByCoBERT

목적

ByCoBERT가 class 단위로 보안 취약점을 예측하도록 훈련시키고 결과 정리

근거

OWASP라는 작은 class-level labeled dataset을 사용했을 때 0.6 정도의 결과를 확인하여 가능성이 있다고 보았음. [KIISE_JOK ByCoBERT]

데이터셋

class 단위 라벨링된 Java project들

  • 1안 : 캡스톤2에서 사용한 mvnrepo의 project들 [mvnCrawler/test_300_300]
  • 2안 : Java_Juliet_1.3의 class들을 취약한 파일과 안전한 파일로 분리 [BKJ-Juliet]

알고리즘

기존 ByCoBERT에서 project 단위로 분할한 것을 class 단위로 분할하도록 수정 [ByCoBERT/pretrainByteBERT.py]

결과

class 단위로 confusion matrix 표현하기

주요 일정

  • 5/1 프로젝트 시작
  • 5/7 Proposal 제출
  • 6/14 발표(video) 제출
  • 총 45일(6주)

[DL] 5. Practical Methodology and Applications

in Study on AI

Deep Learning을 정리하겠다.

13. Linear Factor Model

선형 인자 모델은 latent variable을 가진 가장 단순한 입력 확률 모형을 말한다. latent variable은 관찰 가능한 변수들의 상호관계를 설명하기 위한 개념적인 변수이다. 입력 확률 모형은 주어진 입력에 대한 출력으로 확률 분포를 지원한다. 선형 인자 모델은 단순한 분포를 가진 explanatory factor를 도출할 수 있기 때문에 유용하다. 주로 mixture 모델이나, 커다란 deep probabilistic 모델, generative 모델을 구성하는데 사용된다. 일반적인 성형 인자 모델의 구조는 \(x=Wp(h) + b + noise\) 이다. 위에 방정식에서 어떤 분포의 noise를 사용하는지, 어떤 사전분포 p(h)를 사용하는지에 따라 확률적 PCA, 인자분석, ICA 등으로 구별된다.

Pagination