Общие требования

Начало - договор об оказании услуги. В нем указываются юридические, технические, временнЫе, ... рамки и ограничения, ответственность сторон. Часть вышеуказанной информации попадает в отчет.

Основа хорошего отчета закладывается перед началом тестирования. 

Внутренние требования

Шаг 1. Выбор стандарта оценки уязвимостей. Стандарт CVSS v3 используется для оценки технической серьезности уязвимости. Стандарт OWASP Risk Rating Methodology используется для оценки рисков web приложения для бизнеса. Иногда рекомендуют использовать оба стандарта.

Шаг 2. Используемая среда / правила оформления / способ хранения информации о найденных уязвимостях. Упоминаются Dradis, CherryTree, OneNote. В правилах оформления определяется набор данных для каждой уязвимости (например дата и время проведения, скриншоты, формат описания последовательности действий). 

ДляВариант каждойструктуры.

найденной

1 уязвимостиВсту­питель­ная часть
1.1 Клас­сифика­тор най­ден­ных уяз­вимос­тей
2. Общее опи­сание про­делан­ной работы
3. Тех­ничес­кий отчет
4. Рекомен­дации по устра­нению уяз­вимос­тей

Вступительная часть
Фак­ты, извес­тные исполнителю и заказ­чику до начала работ. К ним отно­сят­ся: дата про­веде­ния пен­теста, методи­ка, которая применя­лась (очень крат­ко), основные эта­пы тес­тирова­ния, перечень сис­тем для тес­тирова­ния и исклю­чения из объ­ема работ, перечень узлов, а так­же методи­ки, которые исполнитель обя­зуется не при­менять (соци­аль­ную инже­нерию или ата­ки на отказ в обслу­жива­нии).

Классификатор уязвимостей
Таб­лица необ­ходима для понимания кри­тери­ев опре­деления кри­тич­ности уяз­вимос­тей, а так­же тот ущерб, который они могут нанес­ти в слу­чае успешной реали­зации.

В зак­лючении всту­питель­ной час­ти необходимо указатьописать уточнения договора, акту­ализированные на эта­пе тес­тирова­ния. Нап­ример, просьба обратить осо­бое вни­мание на какой‑то новый сер­вис, который появил­ся за неделю до начала тес­тирова­ния, или, наобо­рот, в пос­ледний момент поп­росил исклю­чить из иссле­дова­ния веб‑при­ложе­ние, уяз­вимос­ти в котором наш­ли сво­ими силами бук­валь­но за день до начала работ и которое собира­ются капиталь­но дорабо­тать преж­де, чем вновь показы­вать поль­зовате­лям.

Общее описание проделанной работы
Этот раз­дел дол­жен содер­жать зна­чимую для руково­дите­лей ком­пании‑заказ­чика информа­цию о про­делан­ной работе и ее резуль­татах. Глав­ные тре­бова­ния, предъ­явля­емые к нему, — понят­ность и крат­кость. Сам отчет может рас­тянуть­ся на десят­ки, если не сот­ни стра­ниц. Руково­дитель не всег­да готов читать докумен­тацию такого объ­ема, и зачас­тую в этом нет необ­ходимос­ти. Глав­ное — понять кри­тичес­ки важ­ные резуль­таты для при­нятия даль­нейших решений. Наша задача в этом раз­деле — зав­ладеть вни­мани­ем читате­ля с любым уров­нем под­готов­ки, опи­сать общую ситу­ацию и сооб­щить о наибо­лее зна­чимых выводах.

Технический отчет
Пред­назна­чен для тех­ничес­ких спе­циалис­тов. В нем мы, как инже­неры, объ­ясня­ем дру­гим тех­ничес­ким спе­циалис­там, что мы наш­ли при тес­тирова­нии и чем это может гро­зить.

Вариант - отчет в виде кар­точек по най­ден­ным уяз­вимос­тям с раз­делами:

Крат­кое опи­сание най­ден­ного.	Прос­то и дос­тупно опи­сыва­ем, что уда­лось най­ти, что прив­лекло наше вни­мание.
Уро­вень рис­ка.	Прос­тавля­ем бал­лы по той шка­ле, о которой говори­лось ранее.
Ука­зание мес­тонахож­дения в сис­теме.	Ука­зыва­ем IP-адрес, DNS-имя или что‑то, что однознач­но иден­тифици­рует сис­тему.
Опи­сание инс­тру­мен­тария.	Это необя­затель­ный пункт, но он может очень помочь инже­нерам со сто­роны заказ­чика, ког­да они решат вос­про­извести твои дей­ствия.
Ссыл­ка на опи­сание уяз­вимос­ти.	Что­бы чрез­мерно не уве­личи­вать раз­меры отче­та, рекомен­дуем сде­лать внеш­ние ссыл­ки на опи­сания уяз­вимос­тей из откры­тых баз зна­ний. Выб­рать мож­но любую,  нап­ример cve.mitre.org, cvedetails.com, snyk.io или rapid7.com.
Скрин­шоты и дру­гие под­твержде­ния.	Скрин­шоты нуж­но добав­лять толь­ко при усло­вии, что они наг­лядно что‑то объ­ясня­ют.
Ре­комен­дации, как испра­вить уяз­вимость.	В этом раз­деле нуж­но при­вес­ти рекомен­дации про­изво­дите­ля уяз­вимого прог­рам­мно­го обес­печения или свои собс­твен­ные. В любом слу­чае ответс­твен­ность за устра­нение уяз­вимос­тей лежит на заказ­чике и толь­ко ему решать, как они будут устра­нены и будут ли.

 

Источники:

Статья на Хакере

CVSS V 3.1 Calculator