内部审计报告的结构和内容

《内部审计专业实务标准》指出；虽然审计报告的结构和内容可以依据组织和审计类别而变化，但至少应该说明审计的目标、范围和结果，并可以包括适当的背景信息。下面，我们根据该“标准”的一般准则和细则的一般要求，来说明在大多数最终审计报告中都反映了的五个组成部分：背景介绍；审计目标和范围；审计意见和结果；被审查者的评论；其他事项。这些组成部分构成了现行最终审计报告的总体结构和内容要求。它们是综合性报告的提纲，可以有弹性。

1．背景介绍

这一部分是报告的序言或前言，一般篇幅不应太长，其主要目的在于为读者了解审计主题提供必要的解释性资料。

背景介绍可以简明扼要地说明所审计的组织单位和活动，描述其主要特征；说明在报告之前对审计发现、意见(结论)和建议的有关情况，还可以说明报告是否包括了审计的日程和所要求的答复。如果是企业管理当局或董事会审计委员会所要求完成的特殊任务，应该首先指明这一点，并简明说明被审查者的目标、权力和责任范围。

2．目标(目的)和范围

目标的说明应该阐述审计的意图，必要时还可以申述审计的理由和预期的目标。准确地说明审计的目的并按照适当的逻辑顺序来说明达到目标的活动及其结果，能够给读者清晰地展示一条贯穿整个报告的中心主线，为读者了解报告其余部分的内容提供符合逻辑的思维。目的说明应该准确，并可适当具体一点。 范围说明要明确指出所审计的活动和所包含的期间。由于审计范围受到审计目的、目标和准备工作结果的共同影响和制约，可能与年度审计计划或最初拟定的范围不一致。因此，在必要的情况下，范围说明应该清楚地指明所审查的具体领域及其原因，还可以适当地指出每一个审计领域的工作深度。

报告中的范围和目的的说明往往结合在一起，成为一个部分，并力图使读者明确该项审计，审查了什么，为什么审查这些活动而没有审查另外一些活动。但是，这一部分应该避免将达到目标、目的的具体审计步骤和方法列示在内，因为企业高层管理人员想知道的往往是内部审计人员做了些什么及其原因和结果，而

1

不是怎么做。

3．意见和结果

审计结果是审计检查和评价活动的最终成果，一般包括审计发现、结论(意见)和建议三部分。

审计意见是内部审计人员对审计发现所作的职业判断和评价结果，它表明了审计人员对被审查活动所持的态度和看法。尽管不是所有的内部审计组织都要求对审计发现的事实进行全面综合评价，但是，阅读报告的高层管理人员却往往需要这种意见。因此，一些内部审计组织都要求在审计报告中表述审计意见。

通常，说明不良状况的审计发现(消极审计发现)应该成为审计报告的核心部分。在审计报告中，客观准确地说明消极审计发现是非常重要的。一份好的审计报告应该准确地说明审计发现的特征及其前因后果，并能够反映“审计”的过程，使报告的阅读者认同所反映的事实和意见。审计发现的写作应该具有符合逻辑的思维。所有的审计发现都应该包括以下几个方面：

(1) 说明情况——目前的实际状况是什么，即“实际怎样”；

(2) 审计标准——所审计活动适用的评判或审计标准，即“应该怎样”；

(3) 影响或后果——目前状况有何不良影响，或造成了什么样的结果；

(4) 产生原因——导致目前状况的真实原因，即“为什么”。

建议是内部审计人员根据审计发现和意见(结论)提出的改进不良状况的措施或纠正行动。审计报告所提出的审计建议应该与审计发现存在必然的联系。确切地讲，建议必须针对所存在的问题或缺陷的原因提出，否则，就成了“无的放矢”。例如，如果报告的消极审计发现是废旧物资或设备的清理、报废、降价出售等缺乏必要的控制程序，那么，与之相联系的建议则应该包括建立一项控制制度，并贯彻落实。

报告中的建议可以是概括性的，也可以是具体的，但任何一条建议都应该有利于组织目标的实现，符合成本效益原则，并应该是切实可行的。只有这样，才能使有权对之采取行动的管理人员接受并将其付诸实施。

4．被审计单位对审计结果的意见

内部审计人员应当与被审计单位适当层次的管理人员或经理讨论审计的意见和建议，并将被审计者的意见写入审计报告。

2

这部分主要说明被审计者对审计中发现的问题和缺陷所表述的与审计人员不同的意见和看法。如果双方对报告的所有方面都达到了共识，则不必将被审计者的每项具体观点都写入审计报告，如果对有关重要事项存在严重分歧且讨论没有达成一致性意见，则应该如实地反映在审计报告中，供上级管理者评判。

应当强调，对审计发现所揭示的事实，双方不应该存在分歧。为避免不应有的争执，内部审计人员通常根据实际需要将被审计对象对审计报告的书面答复作为报告的一部分。这既可以避免因争执带来的感情伤害，又迫使被审计对象认真考虑并证实审计人员所认定的问题和建议中所提出的改进措施。

5．其他相关内容

其他相关事宜主要指与本次审计任务没有直接关系或关系不重要的某些方面的情况。它可能是一些不重要但应该引起关注的不良倾向，也可能是被审计单位要求审计人员向企业管理当局反映的一些实际困难，等等。有时，高层管理人员临时要求关心的一些事项或后续审计结果的有关情况也包括在这一部分中。

最终审计报告的结构组成通常应该包括上述五个方面的内容，但这并非意味这些就是最完美的规范格式。在实际编制审计报告过程中，可能不同的组织都有自己的适用格式。

审计报告是根据审计工作底稿和期中审计报告所包含的信息编写的。要达到报告的目的，良好的写作是关键的，是审计报告质量好坏的决定因素。

报告应致力于达到的目标。审计报告必须客观、清晰、简洁，而且应该及时。这是审计报告的写作应该达到的标准。

另外，适当的语调也是必须认真考虑的。

以上这些标准已成为内部审计报告，尤其是最终审计报告必须的质量特征。

3

第二篇：代码审计报告

源代码审计报告

一.  概述

1.1  源代码审计概述

源代码审计工作通过分析当前应用系统的源代码，熟悉业务系统，从应用系统结构方面检查其各模块和功能之间的关联、权限验证等内容；从安全性方面检查其脆弱性和缺陷。在明确当前安全现状和需求的情况下，对下一步的编码安全规范性建设有重大的意义。

源代码审计工作利用一定的编程规范和标准，针对应用程序源代码，从结构、脆弱性以及缺陷等方面进行审查，以发现当前应用程序中存在的安全缺陷以及代码的规范性缺陷。

审核目的

本次源代码审计工作是通过对当前系统各模块的源代码进行审查，以检查代码在程序编写上可能引起的安全性和脆弱性问题。

审核依据

本次源代码审计工作主要突出代码编写的缺陷和脆弱性，以OWASP TOP 10 2010为检查依据，针对OWASP统计的问题作重点检查。

  ß点击打开文档OWASP TOP 10 2010

审计范围

根据XX给出的代码，对其WEB应用作脆弱性和缺陷、以及结构上的检查。通过了解业务系统，确定重点检查模块以及重要文件，提供可行性的解决方法。

审计方法

通过白盒（代码审计）的方式检查应用系统的安全性，白盒测试所采用的方法是工具审查+人工确认+人工抽取代码检查，依照OWASP 20## TOP 10所披露的脆弱性，根据业务流来检查目标系统的脆弱性、缺陷以及结构上的问题。

本次源代码审计分为三个阶段：

信息收集

此阶段中，源代码审计人员熟悉待审计WEB应用的结构设计、功能模块，并与客户相关人员商议、协调审计重点及源代码提供等方面的信息。

代码安全性分析

此阶段中，源代码审计人员会使用工具对源代码的脆弱性和安全缺陷进行初步的分析，然后根据客户关注的重点对部分代码进行手工审计，主要包含以下内容：

Ø   输入/输出验证。SQL注入、跨站脚本、拒绝服务攻击，对上传文件的控制等因为未能较好的控制用户提交的内容造成的问题；

Ø   安全功能。请求的参数没有限制范围导致信息泄露，Cookie超时机制和有效域控制，权限控制、日志审计等方面的内容；

Ø   程序异常处理。忽略处理的异常、异常处理不恰当造成的信息泄露或是不便于进行错误定位等问题；

代码规范性检查

此阶段中，源代码审计人员主要是利用一些代码规范检查工具对网站各功能模块的代码进行合规性检查，主要目的在于提高代码质量，使其更符合编码规范的要求，主要包括以下内容：

Ø   代码质量。例如对象错误或不适合调用导致程序未能按预期的方式执行，功能缺失；类成员与其封装类同名，变量赋值后不使用等；

Ø   封装。多余的注释信息、调试信息问题导致应用系统信息暴露，错误的变量声明等。

Ø   API滥用。例如调用非本单位直接控制的资源、对象过于频繁调用、直接调用空对象导致系统资源消耗过大或是程序执行效率低下等问题。

1.2  项目概述

在XX及WEB应用开发单位XX公司相关人员的协调与配合下，**公司安全测试小组于XXXX年XX月XX日至XX日对XX应用进行了源代码审计工作。在此期间内，**公司安全测试小组利用各种主流的代码审计工具以及手工检查等方式对网站主要功能模块的源代码进行了安全性及规范性检查，发现了源代码中存在的一些脆弱性、合规性问题及缺陷。

本文档即为**公司安全测试小组在进行代码审计工作完成后所提交的报告资料，用于对XXWEB应用的安全状况从代码层面作出分析和建议。

**公司代码审计服务是经过授权的，也是有时间限制的。

二.  审核对象

2.1  应用列表

本次代码审核的对象包括：

2.2  参与人员

2.3  审计工具

… …

三.  现状分析

XX门户网站是由XX公司开发的基于XXX语言的网站，主要功能有产品及解决方案、合作伙伴、客户支持、工作机会、eDM以及贯穿多个模块的讨论组。根据模块的不同进行访问权限的控制。

整个网站采用唯一的访问入口default.aspx，所有模块均由系统根据权限和参数来进行控制。系统用户根据权限的不同分为超级管理员、模块管理员和用户三个级别。前台用户访问使用HTTP协议，后台管理员维护使用HTTPS协议，以保证通讯安全。

除了产品及解决方案、合作伙伴、讨论组、工作机会、客户支持五个模块进行了定制开发以外，整个网站的基础架构（如用户管理、权限管理、网站安全、文件上传下载等）均采用成熟的平台来构建。因此，最可能出现各种问题的地方也集中在各个定制模块当中，源代码审计的重点也集中在这几部分的代码上。

四.  审计结果

4.1  XX模块

4.1.1  XXXXXX

4.1.2  XXXXXX

五.  审计结论与建议

5.1  审计结果简评

通过对XX WEB应用进行为期XX天的源代码审计，我们得出如下结论：

底层平台采用了较为成熟的用户管理、权限控制、模块动态加载及访问控制技术，代码的编写基本符合编码规范的要求。但在部分功能模块上还存在一些问题，需要加于改进，主要体现在以下几个方面：

ü  XXXXXX

… …

ü  XXXXXX

… …

注意事项

5.2  脆弱性和缺陷编程意见

经过本次代码审计，也发现了被检测WEB应用存在的一些问题或缺陷，在本节我们会根据我们的经验来提出一些改进意见或建议，供WEB应用开发、管理人员参考。这部分内容对于后期的维护和扩展也有一定的指导意义。

ü  永远不要相信用户的输入

用户的输入主要包括以下几类：

Ø  WEB访问请求中URL的参数部分；

Ø  HTML表单通过POST或GET请求提交的数据 ；

Ø  在客户端临时保存的数据（也就是Cookie）；

Ø  数据库查询。

ü  安全功能方面

Ø  不要过于信任应用程序访问控制规则；

Ø  身份鉴别系统和会话管理可能会被绕过或是被篡改；

Ø  存储的敏感信息可能被抽取。

ü  其它：

Ø  服务器：安装最新的补丁，降低WEB应用运行用户的权限，适当设置应用所在目录的读写权限。

Ø  WEB服务器软件：不要开启目录浏览、写入、脚本资源访问等功能。

Ø  错误处理：必须关闭详细错误显示，比较好的处理方式是开启错误重定向功能在出错后重定向到指定页面（如网站首页），并且这个页面不能把异常信息发送给客户端，如：

<customErrors mode="On" defaultRedirect="Default.aspx" />

Ø  代码质量：主要是指可用性、可维护性、运行效率、重复代码量等等指标，高质量的代码不仅易于维护，而且运行效率高，因为当受到拒绝服务攻击时可以有效降低对系统的影响。好的代码依赖于合理的系统架构、优秀的程序编写人员和严谨的工作作风。

5.3  定期进行代码抽样审计

虽然我们在本次代码审计中发现了这些问题，并且相信这些安全隐患能够在短时间内解决。我们仍然建议您定期进行类似的安全抽样审计，保障不断发展的动态网络的持续安全。

5.4  系统上线前进行全面的测试

在网站新上线或是部分功能更新时，建议进行全面的测试，确保无问题后再在正式环境中上线使用。

5.5  制定完善的开发文档

应该为网站制定完善的开发文档，不建议在开发过程中实现开发文档要求以外的功能，应该注重并严格遵守以下几方面内容：

ü  输入输出实现

ü  程序变更准则

ü  修改程序代码准则

ü  程序验证准则

ü  功能需求