First draft of Progress Report

LaTeX/paper-blx.bib

+@Comment{$ biblatex control file $}
+@Comment{$ biblatex bcf format version 3.10 $}
+% Do not modify this file!
+%
+% This is an auxiliary file used by the 'biblatex' package.
+% This file may safely be deleted. It will be recreated as
+% required.
+
+@Control{biblatex-control,
+  options = {3.10:0:0:1:0:1:1:0:0:0:0:0:3:3:6:3:0:0:3:1:79:+:+:none},
+}

LaTeX/paper.aux

+\relax 
+\bibstyle{biblatex}
+\bibdata{paper-blx,papers}
+\citation{biblatex-control}
+\abx@aux@refcontext{none/global//global/global}
+\providecommand\hyper@newdestlabel[2]{}
+\providecommand\HyperFirstAtBeginDocument{\AtBeginDocument}
+\HyperFirstAtBeginDocument{\ifx\hyper@anchor\@undefined
+\global\let\oldnewlabel\newlabel
+\gdef\newlabel#1#2{\newlabelxx{#1}#2}
+\gdef\newlabelxx#1#2#3#4#5#6{\oldnewlabel{#1}{{#2}{#3}}}
+\AtEndDocument{\ifx\hyper@anchor\@undefined
+\let\newlabel\oldnewlabel
+\fi}
+\fi}
+\global\let\hyper@last\relax 
+\gdef\HyperFirstAtBeginDocument#1{#1}
+\providecommand\HyField@AuxAddToFields[1]{}
+\providecommand\HyField@AuxAddToCoFields[2]{}
+\citation{snyk_why_nodate}
+\abx@aux@cite{0}{snyk_why_nodate}
+\abx@aux@segm{0}{0}{snyk_why_nodate}
+\citation{hutchison_empirical_2013}
+\abx@aux@cite{0}{hutchison_empirical_2013}
+\abx@aux@segm{0}{0}{hutchison_empirical_2013}
+\@writefile{toc}{\contentsline {chapter}{\numberline {1}Project Introduction}{1}{chapter.1}\protected@file@percent }
+\@writefile{lof}{\addvspace {10\p@ }}
+\@writefile{lot}{\addvspace {10\p@ }}
+\@writefile{toc}{\contentsline {section}{\numberline {1.1}What is ACR?}{1}{section.1.1}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {1.2}Project Description}{1}{section.1.2}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {1.3}Scope}{1}{section.1.3}\protected@file@percent }
+\citation{noauthor_syntactic_nodate}
+\abx@aux@cite{0}{noauthor_syntactic_nodate}
+\abx@aux@segm{0}{0}{noauthor_syntactic_nodate}
+\citation{gosain_static_2015}
+\abx@aux@cite{0}{gosain_static_2015}
+\abx@aux@segm{0}{0}{gosain_static_2015}
+\citation{allen_program_1976}
+\abx@aux@cite{0}{allen_program_1976}
+\abx@aux@segm{0}{0}{allen_program_1976}
+\citation{aiken_introduction_1999}
+\abx@aux@cite{0}{aiken_introduction_1999}
+\abx@aux@segm{0}{0}{aiken_introduction_1999}
+\citation{noauthor_misra_2020}
+\abx@aux@cite{0}{noauthor_misra_2020}
+\abx@aux@segm{0}{0}{noauthor_misra_2020}
+\citation{noauthor_sei_nodate}
+\abx@aux@cite{0}{noauthor_sei_nodate}
+\abx@aux@segm{0}{0}{noauthor_sei_nodate}
+\citation{harness_static_nodate}
+\abx@aux@cite{0}{harness_static_nodate}
+\abx@aux@segm{0}{0}{harness_static_nodate}
+\citation{noauthor_splint_nodate}
+\abx@aux@cite{0}{noauthor_splint_nodate}
+\abx@aux@segm{0}{0}{noauthor_splint_nodate}
+\citation{holzmann__nodate}
+\abx@aux@cite{0}{holzmann__nodate}
+\abx@aux@segm{0}{0}{holzmann__nodate}
+\citation{noauthor_cppcheck_2023}
+\abx@aux@cite{0}{noauthor_cppcheck_2023}
+\abx@aux@segm{0}{0}{noauthor_cppcheck_2023}
+\citation{sourceforge_cppcheck_nodate}
+\abx@aux@cite{0}{sourceforge_cppcheck_nodate}
+\abx@aux@segm{0}{0}{sourceforge_cppcheck_nodate}
+\@writefile{toc}{\contentsline {chapter}{\numberline {2}Literature, Current Tools and Limitations}{2}{chapter.2}\protected@file@percent }
+\@writefile{lof}{\addvspace {10\p@ }}
+\@writefile{lot}{\addvspace {10\p@ }}
+\@writefile{toc}{\contentsline {section}{\numberline {2.1}Methods for Static Analysis}{2}{section.2.1}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {2.2}Coding Standards}{2}{section.2.2}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {2.3}Analysis Tools}{2}{section.2.3}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.3.1}Static Analysis}{2}{subsection.2.3.1}\protected@file@percent }
+\citation{harness_static_nodate}
+\abx@aux@cite{0}{harness_static_nodate}
+\abx@aux@segm{0}{0}{harness_static_nodate}
+\citation{noauthor_valgrind_nodate}
+\abx@aux@cite{0}{noauthor_valgrind_nodate}
+\abx@aux@segm{0}{0}{noauthor_valgrind_nodate}
+\citation{noauthor_software_nodate}
+\abx@aux@cite{0}{noauthor_software_nodate}
+\abx@aux@segm{0}{0}{noauthor_software_nodate}
+\citation{noauthor_ldra_nodate}
+\abx@aux@cite{0}{noauthor_ldra_nodate}
+\abx@aux@segm{0}{0}{noauthor_ldra_nodate}
+\citation{noauthor_coverity_nodate}
+\abx@aux@cite{0}{noauthor_coverity_nodate}
+\abx@aux@segm{0}{0}{noauthor_coverity_nodate}
+\citation{noauthor_truth_nodate}
+\abx@aux@cite{0}{noauthor_truth_nodate}
+\abx@aux@segm{0}{0}{noauthor_truth_nodate}
+\citation{noauthor_cost_nodate}
+\abx@aux@cite{0}{noauthor_cost_nodate}
+\abx@aux@segm{0}{0}{noauthor_cost_nodate}
+\citation{noauthor_52_nodate}
+\abx@aux@cite{0}{noauthor_52_nodate}
+\abx@aux@segm{0}{0}{noauthor_52_nodate}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.3.2}Dynamic Analysis}{3}{subsection.2.3.2}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {2.4}Automatic Code Review Tools}{3}{section.2.4}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {2.5}CWE Top 25 Coverage}{3}{section.2.5}\protected@file@percent }
+\newlabel{cwe25coverage}{{2.5}{3}{CWE Top 25 Coverage}{section.2.5}{}}
+\citation{gosain_static_2015}
+\abx@aux@cite{0}{gosain_static_2015}
+\abx@aux@segm{0}{0}{gosain_static_2015}
+\citation{chatzieleftheriou_test-driving_2011}
+\abx@aux@cite{0}{chatzieleftheriou_test-driving_2011}
+\abx@aux@segm{0}{0}{chatzieleftheriou_test-driving_2011}
+\citation{assal_think_2019}
+\abx@aux@cite{0}{assal_think_2019}
+\abx@aux@segm{0}{0}{assal_think_2019}
+\@writefile{toc}{\contentsline {section}{\numberline {2.6}The effects of False Positives}{4}{section.2.6}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.6.1}Why are False Positives so common?}{4}{subsection.2.6.1}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.6.2}Mitigations}{4}{subsection.2.6.2}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {2.7}Conclusion}{4}{section.2.7}\protected@file@percent }
+\gdef \LT@i {\LT@entry 
+    {1}{59.77835pt}\LT@entry 
+    {1}{88.56743pt}\LT@entry 
+    {1}{41.59622pt}\LT@entry 
+    {1}{60.85635pt}\LT@entry 
+    {1}{163.19095pt}}
+\@writefile{toc}{\contentsline {chapter}{\numberline {3}Proposed Design of final system}{5}{chapter.3}\protected@file@percent }
+\@writefile{lof}{\addvspace {10\p@ }}
+\@writefile{lot}{\addvspace {10\p@ }}
+\@writefile{toc}{\contentsline {section}{\numberline {3.1}Justification of Design}{5}{section.3.1}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {3.2}Testing}{5}{section.3.2}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {3.3}Risk Assessment}{5}{section.3.3}\protected@file@percent }
+\@writefile{toc}{\contentsline {chapter}{\numberline {4}Tasking}{8}{chapter.4}\protected@file@percent }
+\@writefile{lof}{\addvspace {10\p@ }}
+\@writefile{lot}{\addvspace {10\p@ }}
+\@writefile{toc}{\contentsline {section}{\numberline {4.1}Schedule}{8}{section.4.1}\protected@file@percent }
+\abx@aux@read@bbl@mdfivesum{CCAE35F002433D86EB5105905A305CB3}
+\abx@aux@defaultrefcontext{0}{snyk_why_nodate}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{hutchison_empirical_2013}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{noauthor_syntactic_nodate}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{gosain_static_2015}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{allen_program_1976}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{aiken_introduction_1999}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{noauthor_misra_2020}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{noauthor_sei_nodate}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{harness_static_nodate}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{noauthor_splint_nodate}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{holzmann__nodate}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{noauthor_cppcheck_2023}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{sourceforge_cppcheck_nodate}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{noauthor_valgrind_nodate}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{noauthor_software_nodate}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{noauthor_ldra_nodate}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{noauthor_coverity_nodate}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{noauthor_truth_nodate}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{noauthor_cost_nodate}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{noauthor_52_nodate}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{chatzieleftheriou_test-driving_2011}{none/global//global/global}
+\abx@aux@defaultrefcontext{0}{assal_think_2019}{none/global//global/global}
+\abx@aux@defaultlabelprefix{0}{snyk_why_nodate}{}
+\abx@aux@defaultlabelprefix{0}{hutchison_empirical_2013}{}
+\abx@aux@defaultlabelprefix{0}{noauthor_syntactic_nodate}{}
+\abx@aux@defaultlabelprefix{0}{gosain_static_2015}{}
+\abx@aux@defaultlabelprefix{0}{allen_program_1976}{}
+\abx@aux@defaultlabelprefix{0}{aiken_introduction_1999}{}
+\abx@aux@defaultlabelprefix{0}{noauthor_misra_2020}{}
+\abx@aux@defaultlabelprefix{0}{noauthor_sei_nodate}{}
+\abx@aux@defaultlabelprefix{0}{harness_static_nodate}{}
+\abx@aux@defaultlabelprefix{0}{noauthor_splint_nodate}{}
+\abx@aux@defaultlabelprefix{0}{holzmann__nodate}{}
+\abx@aux@defaultlabelprefix{0}{noauthor_cppcheck_2023}{}
+\abx@aux@defaultlabelprefix{0}{sourceforge_cppcheck_nodate}{}
+\abx@aux@defaultlabelprefix{0}{noauthor_valgrind_nodate}{}
+\abx@aux@defaultlabelprefix{0}{noauthor_software_nodate}{}
+\abx@aux@defaultlabelprefix{0}{noauthor_ldra_nodate}{}
+\abx@aux@defaultlabelprefix{0}{noauthor_coverity_nodate}{}
+\abx@aux@defaultlabelprefix{0}{noauthor_truth_nodate}{}
+\abx@aux@defaultlabelprefix{0}{noauthor_cost_nodate}{}
+\abx@aux@defaultlabelprefix{0}{noauthor_52_nodate}{}
+\abx@aux@defaultlabelprefix{0}{chatzieleftheriou_test-driving_2011}{}
+\abx@aux@defaultlabelprefix{0}{assal_think_2019}{}
+\gdef \@abspage@last{12}

LaTeX/paper.blg

+This is BibTeX, Version 0.99d
+Capacity: max_strings=200000, hash_size=200000, hash_prime=170003
+The top-level auxiliary file: paper.aux
+Reallocating 'name_of_file' (item size: 1) to 9 items.
+The style file: biblatex.bst
+Reallocating 'name_of_file' (item size: 1) to 10 items.
+Reallocating 'name_of_file' (item size: 1) to 7 items.
+Reallocating 'glb_str_end' (item size: 4) to 20 items.
+Reallocating 'glb_str_ptr' (item size: 4) to 20 items.
+Reallocating 'global_strs' (item size: 1) to 4000000 items.
+Reallocating 'singl_function' (item size: 4) to 100 items.
+Reallocating 'singl_function' (item size: 4) to 100 items.
+Reallocating 'singl_function' (item size: 4) to 100 items.
+Reallocating 'wiz_functions' (item size: 4) to 6000 items.
+Reallocating 'singl_function' (item size: 4) to 100 items.
+Reallocating 'singl_function' (item size: 4) to 100 items.
+Reallocating 'singl_function' (item size: 4) to 100 items.
+Reallocating 'singl_function' (item size: 4) to 100 items.
+Reallocating 'singl_function' (item size: 4) to 100 items.
+Reallocating 'singl_function' (item size: 4) to 100 items.
+Reallocating 'singl_function' (item size: 4) to 100 items.
+Reallocating 'singl_function' (item size: 4) to 100 items.
+Database file #1: paper-blx.bib
+Database file #2: papers.bib
+Biblatex version: 3.19
+Reallocating 'wiz_functions' (item size: 4) to 9000 items.
+Reallocating 'singl_function' (item size: 4) to 100 items.
+You've used 23 entries,
+            6399 wiz_defined-function locations,
+            1376 strings with 24702 characters,
+and the built_in function-call counts, 177058 in all, are:
+= -- 10490
+> -- 10350
+< -- 882
++ -- 11808
+- -- 8682
+* -- 9254
+:= -- 22937
+add.period$ -- 0
+call.type$ -- 23
+change.case$ -- 214
+chr.to.int$ -- 798
+cite$ -- 44
+duplicate$ -- 16581
+empty$ -- 13732
+format.name$ -- 762
+if$ -- 28869
+int.to.chr$ -- 0
+int.to.str$ -- 43
+missing$ -- 0
+newline$ -- 796
+num.names$ -- 526
+pop$ -- 7638
+preamble$ -- 1
+purify$ -- 290
+quote$ -- 0
+skip$ -- 3571
+stack$ -- 0
+substring$ -- 20528
+swap$ -- 3731
+text.length$ -- 681
+text.prefix$ -- 0
+top$ -- 1
+type$ -- 770
+warning$ -- 0
+while$ -- 2282
+width$ -- 0
+write$ -- 774

LaTeX/paper.out

+\BOOKMARK [0][-]{chapter.1}{\376\377\000P\000r\000o\000j\000e\000c\000t\000\040\000I\000n\000t\000r\000o\000d\000u\000c\000t\000i\000o\000n}{}% 1
+\BOOKMARK [1][-]{section.1.1}{\376\377\000W\000h\000a\000t\000\040\000i\000s\000\040\000A\000C\000R\000?}{chapter.1}% 2
+\BOOKMARK [1][-]{section.1.2}{\376\377\000P\000r\000o\000j\000e\000c\000t\000\040\000D\000e\000s\000c\000r\000i\000p\000t\000i\000o\000n}{chapter.1}% 3
+\BOOKMARK [1][-]{section.1.3}{\376\377\000S\000c\000o\000p\000e}{chapter.1}% 4
+\BOOKMARK [0][-]{chapter.2}{\376\377\000L\000i\000t\000e\000r\000a\000t\000u\000r\000e\000,\000\040\000C\000u\000r\000r\000e\000n\000t\000\040\000T\000o\000o\000l\000s\000\040\000a\000n\000d\000\040\000L\000i\000m\000i\000t\000a\000t\000i\000o\000n\000s}{}% 5
+\BOOKMARK [1][-]{section.2.1}{\376\377\000M\000e\000t\000h\000o\000d\000s\000\040\000f\000o\000r\000\040\000S\000t\000a\000t\000i\000c\000\040\000A\000n\000a\000l\000y\000s\000i\000s}{chapter.2}% 6
+\BOOKMARK [1][-]{section.2.2}{\376\377\000C\000o\000d\000i\000n\000g\000\040\000S\000t\000a\000n\000d\000a\000r\000d\000s}{chapter.2}% 7
+\BOOKMARK [1][-]{section.2.3}{\376\377\000A\000n\000a\000l\000y\000s\000i\000s\000\040\000T\000o\000o\000l\000s}{chapter.2}% 8
+\BOOKMARK [2][-]{subsection.2.3.1}{\376\377\000S\000t\000a\000t\000i\000c\000\040\000A\000n\000a\000l\000y\000s\000i\000s}{section.2.3}% 9
+\BOOKMARK [2][-]{subsection.2.3.2}{\376\377\000D\000y\000n\000a\000m\000i\000c\000\040\000A\000n\000a\000l\000y\000s\000i\000s}{section.2.3}% 10
+\BOOKMARK [1][-]{section.2.4}{\376\377\000A\000u\000t\000o\000m\000a\000t\000i\000c\000\040\000C\000o\000d\000e\000\040\000R\000e\000v\000i\000e\000w\000\040\000T\000o\000o\000l\000s}{chapter.2}% 11
+\BOOKMARK [1][-]{section.2.5}{\376\377\000C\000W\000E\000\040\000T\000o\000p\000\040\0002\0005\000\040\000C\000o\000v\000e\000r\000a\000g\000e}{chapter.2}% 12
+\BOOKMARK [1][-]{section.2.6}{\376\377\000T\000h\000e\000\040\000e\000f\000f\000e\000c\000t\000s\000\040\000o\000f\000\040\000F\000a\000l\000s\000e\000\040\000P\000o\000s\000i\000t\000i\000v\000e\000s}{chapter.2}% 13
+\BOOKMARK [2][-]{subsection.2.6.1}{\376\377\000W\000h\000y\000\040\000a\000r\000e\000\040\000F\000a\000l\000s\000e\000\040\000P\000o\000s\000i\000t\000i\000v\000e\000s\000\040\000s\000o\000\040\000c\000o\000m\000m\000o\000n\000?}{section.2.6}% 14
+\BOOKMARK [2][-]{subsection.2.6.2}{\376\377\000M\000i\000t\000i\000g\000a\000t\000i\000o\000n\000s}{section.2.6}% 15
+\BOOKMARK [1][-]{section.2.7}{\376\377\000C\000o\000n\000c\000l\000u\000s\000i\000o\000n}{chapter.2}% 16
+\BOOKMARK [0][-]{chapter.3}{\376\377\000P\000r\000o\000p\000o\000s\000e\000d\000\040\000D\000e\000s\000i\000g\000n\000\040\000o\000f\000\040\000f\000i\000n\000a\000l\000\040\000s\000y\000s\000t\000e\000m}{}% 17
+\BOOKMARK [1][-]{section.3.1}{\376\377\000J\000u\000s\000t\000i\000f\000i\000c\000a\000t\000i\000o\000n\000\040\000o\000f\000\040\000D\000e\000s\000i\000g\000n}{chapter.3}% 18
+\BOOKMARK [1][-]{section.3.2}{\376\377\000T\000e\000s\000t\000i\000n\000g}{chapter.3}% 19
+\BOOKMARK [1][-]{section.3.3}{\376\377\000R\000i\000s\000k\000\040\000A\000s\000s\000e\000s\000s\000m\000e\000n\000t}{chapter.3}% 20
+\BOOKMARK [0][-]{chapter.4}{\376\377\000T\000a\000s\000k\000i\000n\000g}{}% 21
+\BOOKMARK [1][-]{section.4.1}{\376\377\000S\000c\000h\000e\000d\000u\000l\000e}{chapter.4}% 22

LaTeX/paper.run.xml

+<?xml version="1.0" standalone="yes"?>
+<!-- logreq request file -->
+<!-- logreq version 1.0 / dtd version 1.0 -->
+<!-- Do not edit this file! -->
+<!DOCTYPE requests [
+  <!ELEMENT requests (internal | external)*>
+  <!ELEMENT internal (generic, (provides | requires)*)>
+  <!ELEMENT external (generic, cmdline?, input?, output?, (provides | requires)*)>
+  <!ELEMENT cmdline (binary, (option | infile | outfile)*)>
+  <!ELEMENT input (file)+>
+  <!ELEMENT output (file)+>
+  <!ELEMENT provides (file)+>
+  <!ELEMENT requires (file)+>
+  <!ELEMENT generic (#PCDATA)>
+  <!ELEMENT binary (#PCDATA)>
+  <!ELEMENT option (#PCDATA)>
+  <!ELEMENT infile (#PCDATA)>
+  <!ELEMENT outfile (#PCDATA)>
+  <!ELEMENT file (#PCDATA)>
+  <!ATTLIST requests
+    version CDATA #REQUIRED
+  >
+  <!ATTLIST internal
+    package CDATA #REQUIRED
+    priority (9) #REQUIRED
+    active (0 | 1) #REQUIRED
+  >
+  <!ATTLIST external
+    package CDATA #REQUIRED
+    priority (1 | 2 | 3 | 4 | 5 | 6 | 7 | 8) #REQUIRED
+    active (0 | 1) #REQUIRED
+  >
+  <!ATTLIST provides
+    type (static | dynamic | editable) #REQUIRED
+  >
+  <!ATTLIST requires
+    type (static | dynamic | editable) #REQUIRED
+  >
+  <!ATTLIST file
+    type CDATA #IMPLIED
+  >
+]>
+<requests version="1.0">
+  <internal package="biblatex" priority="9" active="1">
+    <generic>latex</generic>
+    <provides type="dynamic">
+      <file>paper.aux</file>
+      <file>paper-blx.bib</file>
+    </provides>
+    <requires type="dynamic">
+      <file>paper.bbl</file>
+    </requires>
+    <requires type="static">
+      <file>blx-dm.def</file>
+      <file>blx-compat.def</file>
+      <file>blx-bibtex.def</file>
+      <file>biblatex.def</file>
+      <file>standard.bbx</file>
+      <file>numeric.bbx</file>
+      <file>numeric-comp.bbx</file>
+      <file>ieee.bbx</file>
+      <file>numeric-comp.cbx</file>
+      <file>ieee.cbx</file>
+      <file>biblatex.cfg</file>
+      <file>english.lbx</file>
+    </requires>
+  </internal>
+  <external package="biblatex" priority="5" active="1">
+    <generic>bibtex</generic>
+    <cmdline>
+      <binary>bibtex</binary>
+      <option>-min-crossrefs 2</option>
+      <infile>paper</infile>
+    </cmdline>
+    <input>
+      <file>paper.aux</file>
+    </input>
+    <output>
+      <file>paper.bbl</file>
+    </output>
+    <provides type="dynamic">
+      <file>paper.bbl</file>
+    </provides>
+    <requires type="dynamic">
+      <file>paper.aux</file>
+      <file>paper-blx.bib</file>
+    </requires>
+    <requires type="editable">
+      <file>papers.bib</file>
+    </requires>
+    <requires type="static">
+      <file>biblatex.bst</file>
+    </requires>
+  </external>
+</requests>

LaTeX/paper.tex

+\documentclass[openany]{book}
+\usepackage{graphicx} % Required for inserting images
+\usepackage{fullpage}
+\usepackage[
+	backend=bibtex,
+	style=ieee
+]{biblatex}
+\usepackage{hyperref}
+\usepackage{array}
+\usepackage[longtable]{multirow}
+\usepackage{longtable}
+
+
+
+\addbibresource{papers.bib}
+
+\title{Developing a Security-focussed Automated Code Review tool for the C language}
+\author{William Pearman (wp2g21)}
+\date{December 2023}
+
+
+\begin{document}
+\frontmatter
+\maketitle
+\tableofcontents
+\mainmatter
+\chapter{Project Introduction}
+\textbf{Write down the goals}, educating new developers on how to use ACR tools, making a new tool that is approachable to all skill sets.
+\section{What is ACR?}
+Automated Code Review (ACR) is the process of removing humans from the action of scanning source code for defects. It does this by comparing the source code against a known standard. These tools excel in issues related to style guidelines, standard errors, bugs and security vulnerabilities. While these tools can produce a range of false positives and negatives, correct usage results in a significant improvement against security threats and performance \cite{snyk_why_nodate}. 
+\newline It is recommended by Security Professionals that you should use multiple code review tools on your codebase \cite{hutchison_empirical_2013}. 
+\section{Project Description}
+A frequent complaint found with Automatic Code Review tools is that they are unapproachable and noisy. This paper discusses the design and development of a proof-of-concept ACR tool that is both approachable and organized, whilst teaching developers how to improve their secure coding skills in the process.
+\section{Scope}
+This project must ensure the analysed output is well understood and easily applicable to the source code. The project will not cover all developer-based security faults, remaining primarily on those within the \textit{\href{https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html}{2023 CWE Top 25 Most Dangerous Software Weaknesses}}. The project will be keeping focus solely on codebases within the C language, and be developed using C\#. Testing will utilise colleagues from the University of Southampton in various years and branches of Computer Science. The testing will not prioritise finding which tool is more accurate, as it is infeasible in the given time frame for the new tool to exceed current Automatic Code Review tools.
+
+\chapter{Literature, Current Tools and Limitations}
+A small description of what this section covers, what the goal of it is, and an analysis of existing code review tools.
+
+\section{Methods for Static Analysis}
+Static analysis has many possible solutions depending on the target bugs and vulnerabilities. \newline
+\textbf{Syntactic Pattern Matching} (SPM) designs pattern classifiers by inferring generative grammars for each class of patterns. These grammars define language classes representing specified coding standards and rules \cite{noauthor_syntactic_nodate}. While SPM is the fastest technique, it is commonly incorrect and has many false positives \cite{gosain_static_2015}. \newline
+\textbf{Data Flow Analysis} (DFA) examines how data flows through a program, highlighting information about the possible values that variables can take and how it affects the program's control flow \cite{allen_program_1976}. DFA is the most common technique used throughout Static Analysis. \newline
+\textbf{Constraint-based Analysis} (CBA) models program behaviour using constraints on variables. It formulates relationships between variables as constraints, representing conditions the program must satisfy. By solving these constraints, the analysis infers properties about the program, such as variable values or potential issues, aiding in optimization and bug detection \cite{aiken_introduction_1999}.
+\section{Coding Standards}
+Standards for secure programming in C aim to reduce the amount of bugs and vulnerabilities. \newline
+The \textbf{MISRA C Coding Standard} is a set of guidelines for the C programming language that promotes safety, security, and reliability in embedded system software used by industries covering automotive, aerospace, defence, industrial automation, and medical devices \cite{noauthor_misra_2020}. \newline
+The \textbf{SEI CERT C Coding Standard} is a set of guidelines and recommendations developed to improve the safety, reliability, and security of software systems written in the C programming language. The standard consists of rules and recommendations providing normative requirements for the code \cite{noauthor_sei_nodate}.
+\section{Analysis Tools}
+\subsection{Static Analysis}
+Static analysis involves verifying the source code against a given set of rules or coding standards, often highlighting vulnerabilities, code-style issues and conflicts against accepted coding standards \cite{harness_static_nodate}. \newline
+\textbf{Splint} (Secure Programming Lint) is a lightweight, modern version of the Unix lint tool that can interpret special annotations to the source code, improving its precision compared to simply looking at the source code alone \cite{noauthor_splint_nodate}. \newline
+\textbf{UNO} is a simple tool that focusses solely on the three most common defects in C code; \href{https://cwe.mitre.org/data/definitions/457.html}{Use of Uninitialized Variables}, \href{https://cwe.mitre.org/data/definitions/457.html}{NULL Pointer Dereference}, \href{https://cwe.mitre.org/data/definitions/1218.html}{Out-of-bounds Array accesses} \cite{holzmann__nodate} where these defects all rank within the \textit{\href{https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html}{2023 CWE Top 25 Most Dangerous Software Weaknesses}}. \newline
+\textbf{Cppcheck} provides robust static checks beyond compiler capabilities, analyzing source code rigorously. It examines automatic variables, array bounds, class elements, deprecated functions, exception safety, memory leaks, and stylistic issues. \cite{noauthor_cppcheck_2023, sourceforge_cppcheck_nodate}.
+\subsection{Dynamic Analysis}
+Dynamic analysis scans the program while running, detecting runtime vulnerabilities such as memory leaks \cite{harness_static_nodate}. \newline
+\textbf{Valgrind} focuses on fixing memory management and threading bugs. It provides detailed feedback to developers, allowing them to control the level of detail in the output \cite{noauthor_valgrind_nodate}.
+\section{Automatic Code Review Tools}
+Automatic Code Review tools are typically a compilation of multiple Static Analysis and Dynamic Analysis tools used in the industry and boast a "one program catches all" approach. They are often closed-source and locked behind a considerable paywall exceeding £3000 per user \cite{noauthor_software_nodate}, making them inaccessible to small teams of developers. \newline
+\textbf{LDRA} is a comprehensive tool suite that provides both static and dynamic software analysis, unit testing, and requirements engineering used across various industries such as avionics, military, automotive, and medical \cite{noauthor_ldra_nodate}.  \newline
+\textbf{Synopsis Coverity} is a comprehensive static analysis tool designed to empower developers and security teams to deliver secure, high-quality applications at scale, providing detailed analysis for 22 programming languages and more than 200 frameworks \cite{noauthor_coverity_nodate}. 
+\section{CWE Top 25 Coverage} \label{cwe25coverage}
+ACR tools cumulatively cover the \textit{\href{https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html}{2023 CWE Top 25 Most Dangerous Software Weaknesses}} that affect the C language, shown below.\newline
+\begin{tabular}{||l|l|l|l||}
+	\hline
+	Rank & CWE-ID  & Name                                                                     & Detected by                                            \\
+	\hline
+	\hline
+	1    & CWE-787 & Out-of-bounds Write                                                      & UNO                                                    \\
+	4    & CWE-416 & Use After Free                                                           & Valgrind                                               \\
+	6    & CWE-20  & Improper Input Validation                                                & CppCheck                                               \\
+	7    & CWE-125 & Out-of-bounds Read                                                       & UNO                                                    \\
+	12   & CWE-476 & NULL Pointer Dereference                                                 & UNO			 										   \\
+	14   & CWE-190 & Integer Overflow or Wraparound                                           & CppCheck                                               \\
+	17   & CWE-119 & Buffer Overflow  														  & Valgrind                                               \\
+	18   & CWE-798 & Use of Hard-coded Credentials                                            & Code Credential Scanner                                \\
+	21   & CWE-362 & Race Condition 														  & Clang                                                  \\
+	25   & CWE-276 & Incorrect Default Permissions                                            & Coverity			                                   \\
+	\hline
+\end{tabular}
+\newline This table shows that a combination of UNO, CppCheck, Valgrind and Code Credential Scanner covers a majority of the major CWEs affecting C codebases.
+\section{The effects of False Positives}
+Automated Code Review tools have an inherent major flaw of having a high False Positive (FPs) rate, with \textit{"40\% of organizations not using ACR tools during the software development life cycle primarily due to the overwhelming number of FPs they generate"} \cite{noauthor_truth_nodate}. While experienced developers have the experience to differentiate between True and FPs, many get trapped investigating issues that don't exist. \newline
+Security teams can spend 21,000 hours annually resolving FPs, costing a total of £1 million \cite{noauthor_cost_nodate}. Due to pressuring business deadlines and worries of job security, this has a resultant effect of 52\% upwards of developers cutting back on vital security measures \cite{noauthor_52_nodate}, increasing the workload and stress on the following Application Security developers.
+\subsection{Why are False Positives so common?}
+Code Analysis requires a careful balance of Precision (Estimation used), Efficiency (Cost of analysis), Scalability (Performance over increasing project size) \cite{gosain_static_2015}. George C. et al \cite{chatzieleftheriou_test-driving_2011} shows the relationship of these factors by testing the capabilities of Splint, UNO, CppCheck, Frama-C, C++ Test and Com. B where shown that by optimising Precision there is an inverse proportional effect on Efficiency. \newline
+\textit{False Positives and Precision can be improved at the cost of significant efficiency loss and increase of time taken.}
+\subsection{Mitigations}
+The most effective method of reducing FPs is to utilise Code Analysis tools from the beginning of development. By using the tools late, the developers will be flooded with various warnings and alerts causing stress and encourage the developer to disregard the tool in order to meet corporate deadlines \cite{assal_think_2019}.\newline 
+By providing more description on issues explaining why the selected statement was highlighted such as what rule had been breached, the developer should be able to make quicker progress through the many highlighted issues.
+\section{Conclusion}
+This Chapter shows that Code Analysis tools additively cover all major CWEs, but suffer significant issues preventing individual and industrial use. ACR highlights the issues with code and expect the developer to understand, setting a high barrier for entry. None of the tools explain why these bugs matter or their significance. These tools may also misguide developers due to the high volume of False Positives they suffer, causing a considerable amount of hours wasted on chasing non-issues.
+\chapter{Proposed Design of final system}
+This paper proposes the development of a new Automated Code Review tool for the C language. The tool will be more accessible to developers with less experience by compiling and presenting the output of existing Static and Dynamic Analysis tools in a more user-friendly manner. The primary objective of the tool is to educate and guide developers by providing clear explanations of what is wrong, what the issue is, and why it matters. The tool will feature an easy-to-use GUI developed in C\#.
+\section{Justification of Design}
+The program will be developed in C\# interfacing several existing Static Analysis tools that analyse C language code, allowing for the primary focus of development to be on researching how to make these tools more approachable.
+The tools interfaced in the developed ACR program will be UNO, CppCheck, Valgrind and Code Credential Scanner, as they were cumulatively shown in \ref{cwe25coverage} to cover a majority of the 2023 CWE Top 25 which are the most common issues regarding security in code.
+
+\section{Testing}
+The \href{https://samate.nist.gov/SARD/test-suites/116}{Juliet C/C++ 1.3.1 test database} developed by the \textit{NSA Center for Assured Software}, containing 64,099 test cases, will be used to test the program's functionality for different CWEs. \newline
+The program will be peer-tested by students of varying cyber security knowledge to use both the developed program and control tool in isolation, and asking which one they found more approachable, if the additional information helped and which they would prefer to use on an actual project. 
+\section{Risk Assessment}
+Over the course of the project, there may be many problems that may interrupt work. This section describes what those risks are and mitigations for each.
+\begin{longtable}{|>{\hspace{0pt}}m{0.1\linewidth}|>{\hspace{0pt}}m{0.163\linewidth}>{\hspace{0pt}}m{0.063\linewidth}>{\hspace{0pt}}m{0.104\linewidth}>{\hspace{0pt}}m{0.321\linewidth}|} 
+	\hline
+	\textbf{Hazard} & \textbf{Description} & \textbf{Likelihood (1-5)} & \textbf{Consequences (if left unmitigated)} & \textbf{Mitigations} \\* 
+	\hline
+	\multirow{3}{0.1\linewidth}{\hspace{0pt}\textbf{Scope Creep}} & \multirow{3}{0.163\linewidth}{\hspace{0pt}The project scope may expand beyond the original plan.} & \multirow{3}{0.063\linewidth}{\hspace{0pt}2} & Increased workload. & 1.~~~~~~~ Stick to the project scope as \textbf{defined in this interim report}. \\*
+	&  &  & Potential delays. & 2.~~~~~~~ Any changes should be \textbf{discussed }with your project supervisor. \\*
+	&  &  &  & 3.~~~~~~~ Any change adjusting the project timeline must have \textbf{substantial evidence for value}. \\* 
+	\hline
+	\multirow{4}{0.1\linewidth}{\hspace{0pt}\textbf{Time Management}} & \multirow{4}{0.163\linewidth}{\hspace{0pt}Modules outside of the 3\textsuperscript{rd} Year Project may require attention.} & \multirow{4}{0.063\linewidth}{\hspace{0pt}4} & Missed deadlines. & 1.~~~~~~~ The 3\textsuperscript{rd} Year Project will be worked on \textbf{10 hours/week}. \textit{Working past 8pm is prohibited without justification.} \\*
+	&  &  & Poor project and/or module quality. & 2.~~~~~~~ The primary working day for the project will be \textbf{Wednesday}. \\*
+	&  &  & Stress, resulting in burnout. & 3.~~~~~~~ If a deadline for another module is due that week, \textbf{prioritise the other module}. \textit{Make record of any occurrences of this.} \\*
+	&  &  &  & 4.~~~~~~~ \textbf{Follow the timeline} as defined in this interim report. \textit{Ensure that Project deadlines are met, and justify any extensions required.} \\* 
+	\hline
+	\multirow{3}{0.1\linewidth}{\hspace{0pt}\textbf{Technology Failures}} & \multirow{3}{0.163\linewidth}{\hspace{0pt}Personal hardware or software failure.} & \multirow{3}{0.063\linewidth}{\hspace{0pt}3} & Prevents progression of project. & 1.~~~~~~~ \textbf{Soton GitLab }will be used to manage the project. \textit{After each working period, push the additions.} \\*
+	&  &  & Data loss. & 2.~~~~~~~ Also keep a \textbf{local, physical backup} of the data on you for the case that GitLab is inaccessible. \\*
+	&  &  & Work setbacks. & 3.~~~~~~~ Should your own devices fail, use the \textbf{Campus lab/library computers} to ensure progression continues. \\* 
+	\hline
+	\multirow{4}{0.1\linewidth}{\hspace{0pt}\textbf{Communication Issues}} & \multirow{4}{0.163\linewidth}{\hspace{0pt}Poor/lack of communication with Supervisor, Peers, or other stakeholders.} & \multirow{4}{0.063\linewidth}{\hspace{0pt}2} & Misunderstanding of project. & 1.~~~~~~~ Have \textbf{weekly meetings} with your supervisor. \\*
+	&  &  & Lack of support. & 2.~~~~~~~ Ensure that you are \textbf{prepared for each meeting} with your supervisor. \\*
+	&  &  &  & 3.~~~~~~~ Bring \textbf{questions} to each meeting to ensure you get the maximum value. \\*
+	&  &  &  & 4.~~~~~~~ In the case that your supervisor is unavailable, \textbf{make a record of the events of that week}. \\* 
+	\hline
+	\multirow{4}{0.1\linewidth}{\hspace{0pt}\textbf{Technical Challenges}} & \multirow{4}{0.163\linewidth}{\hspace{0pt}Unforeseen technical issues or difficulties in understanding concepts.} & \multirow{4}{0.063\linewidth}{\hspace{0pt}4} & Increased workload. & 1.~~~~~~~ Ensure that all progress made is \textbf{well documented} for ease of peer review. \\*
+	&  &  & Potential delays. & 2.~~~~~~~ Ask \textbf{knowledgeable peers} if they have any advice on the matter. \\*
+	&  &  &  & 3.~~~~~~~ Ask \textbf{supervisor} for guidance, such as people to contact for questions. \\*
+	&  &  &  & 4.~~~~~~~ If the challenge is too large, \textbf{change of scope} is justified. \textit{Ensure that reasoning is recorded and well justified.} \\* 
+	\hline
+	\multirow{5}{0.1\linewidth}{\hspace{0pt}\textbf{Difficulties regarding testing data}} & \multirow{5}{0.163\linewidth}{\hspace{0pt}Difficulties in obtaining or analysing test data} & \multirow{5}{0.063\linewidth}{\hspace{0pt}2} & Effects on the validity of the project. & 1.~~~~~~~ Ensure that testing approach is finalized and \textbf{sent for ethics approval }well in advance of data collection. \\*
+	&  &  & Potential delays. & 2.~~~~~~~ Should ethics approval be rejected, discuss options with your supervisor. \\*
+	&  &  &  & 3.~~~~~~~ Gather atleast \textbf{ten participants} for the study from unique backgrounds to ensure diversity. \\*
+	&  &  &  & 4.~~~~~~~ Collected \textbf{personal data} must be anonymised to ensure participant safety. \\*
+	&  &  &  & 5.~~~~~~~ Participants will be given the \textbf{option of withdrawal} at any time. \\* 
+	\hline
+	\multirow{3}{0.1\linewidth}{\hspace{0pt}\textbf{Health Issues}} & \multirow{3}{0.163\linewidth}{\hspace{0pt}Physical or mental health issues. \textit{Also covering for burnout.}} & \multirow{3}{0.063\linewidth}{\hspace{0pt}5} & Potential delays. & 1.~~~~~~~ Ensure that \textbf{frequent breaks are taken} to reduce the risk of repetitive strain injuries. \\*
+	&  &  & Stress, resulting in burnout. & 2.~~~~~~~ \textbf{Prioritize self-recovery} over project progression. \textit{The project timeline will account for potential downtime.} \\*
+	&  &  &  & 3.~~~~~~~ In the case that the issue is persistent, contact your Supervisor and attempt to get a \textbf{project deadline extension}. \\
+	\hline
+\end{longtable}
+
+\chapter{Tasking}
+\section{Schedule}
+An overview of all work to be done until the final hand-in, with estimated completion dates.
+
+\backmatter
+\printbibliography
+
+\end{document}
+

LaTeX/paper.toc

+\contentsline {chapter}{\numberline {1}Project Introduction}{1}{chapter.1}%
+\contentsline {section}{\numberline {1.1}What is ACR?}{1}{section.1.1}%
+\contentsline {section}{\numberline {1.2}Project Description}{1}{section.1.2}%
+\contentsline {section}{\numberline {1.3}Scope}{1}{section.1.3}%
+\contentsline {chapter}{\numberline {2}Literature, Current Tools and Limitations}{2}{chapter.2}%
+\contentsline {section}{\numberline {2.1}Methods for Static Analysis}{2}{section.2.1}%
+\contentsline {section}{\numberline {2.2}Coding Standards}{2}{section.2.2}%
+\contentsline {section}{\numberline {2.3}Analysis Tools}{2}{section.2.3}%
+\contentsline {subsection}{\numberline {2.3.1}Static Analysis}{2}{subsection.2.3.1}%
+\contentsline {subsection}{\numberline {2.3.2}Dynamic Analysis}{3}{subsection.2.3.2}%
+\contentsline {section}{\numberline {2.4}Automatic Code Review Tools}{3}{section.2.4}%
+\contentsline {section}{\numberline {2.5}CWE Top 25 Coverage}{3}{section.2.5}%
+\contentsline {section}{\numberline {2.6}The effects of False Positives}{4}{section.2.6}%
+\contentsline {subsection}{\numberline {2.6.1}Why are False Positives so common?}{4}{subsection.2.6.1}%
+\contentsline {subsection}{\numberline {2.6.2}Mitigations}{4}{subsection.2.6.2}%
+\contentsline {section}{\numberline {2.7}Conclusion}{4}{section.2.7}%
+\contentsline {chapter}{\numberline {3}Proposed Design of final system}{5}{chapter.3}%
+\contentsline {section}{\numberline {3.1}Justification of Design}{5}{section.3.1}%
+\contentsline {section}{\numberline {3.2}Testing}{5}{section.3.2}%
+\contentsline {section}{\numberline {3.3}Risk Assessment}{5}{section.3.3}%
+\contentsline {chapter}{\numberline {4}Tasking}{8}{chapter.4}%
+\contentsline {section}{\numberline {4.1}Schedule}{8}{section.4.1}%