Foreword
This document defines four levels of application-level security verification for Web applications. Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks. Each level described in this document includes a set of requirements for verifying the effectiveness of security controls that protect Web applications.
The requirements were developed with the following objectives in mind:
?Use as a metric – Provide application developers and application owners with a yardstick with which to assess the degree of trust that can be placed in their Web applications, ?Use as guidance – Provide guidance to security control developers as to what to build into security controls in order to satisfy application security requirements,1 and ?Use during procurement – Provide a basis for specifying application security verification requirements in contracts.2
The requirements were designed to meet the above objectives by ensuring validation of how security controls are designed, implemented, and used by an application. The requirements ensure that the security controls used by an application operate using a deny-by-default strategy, are centralized, are located on the server side, and are all used where necessary.
Copyright and License
Copyright ? 2008 – 2009 The OWASP Foundation.
This document is released under the Creative Commons Attribution ShareAlike
3.0 license. For any reuse or distribution, you must make clear to others the
license terms of this work.
1 For more information about building and using security controls that meet ASVS requirements, see the Enterprise Security API (ESAPI) (OWASP, 2009).
2 For more information about using ASVS in contracts, see the Contract Annex (OWASP, 2009).
Table of Contents Introduction (1)
Approach (1)
Acknowledgements (3)
Application Security Verification Levels (4)
Level 1 – Automated Verification (4)
Level 1A – Dynamic Scan (Partial Automated Verification) (6)
Level 1B – Source Code Scan (Partial Automated Verification) (7)
Level 2 – Manual Verification (7)
Level 2A – Security Test (Partial Manual Verification) (10)
Level 2B – Code Review (Partial Manual Verification) (10)
Level 3 – Design Verification (10)
Level 4 – Internal Verification (13)
Requirement Interpretations and Precedents (15)
Detailed Verification Requirements (16)
V1 – Security Architecture Documentation Requirements (17)
V2 – Authentication Verification Requirements (18)
V3 – Session Management Verification Requirements (19)
V4 – Access Control Verification Requirements (20)
V5 – Input Validation Verification Requirements (22)
V6 – Output Encoding/Escaping Verification Requirements (23)
V7 – Cryptography Verification Requirements (24)
V8 – Error Handling and Logging Verification Requirements (25)
V9 – Data Protection Verification Requirements (26)
V10 – Communication Security Verification Requirements (27)
V11 – HTTP Security Verification Requirements (28)
V12 – Security Configuration Verification Requirements (29)
V13 – Malicious Code Search Verification Requirements (30)
V14 – Internal Security Verification Requirements (31)
Verification Reporting Requirements (32)
R1 – Report Introduction (32)
R2 – Application Description (32)
R3 – Application Security Architecture (32)
R4 – Verification Results (33)
Glossary (35)
Where To Go From Here (37)
Figures
Figure 1 – OWASP ASVS Levels (1)
Figure 2 – One way to introduce verification as an activity into your SDLC (2)
Figure 3 – OWASP ASVS Levels 1, 1A, and 1B (5)
Figure 4 – OWASP ASVS Level 1 Security Architecture Example (6)
Figure 5 – OWASP ASVS Levels 2, 2A, and 2B (7)
Figure 6 – OWASP ASVS Level 2 Security Architecture Example (9)
Figure 7 – OWASP ASVS Level 3 (11)
Figure 8 – OWASP ASVS Level 3 Security Architecture Example (12)
Figure 9 – OWASP ASVS Level 4 (13)
Figure 10 – OWASP ASVS Level 4 Unexamined Code Example (15)
Figure 11 – Report Contents (32)
Tables
Table 1 – OWASP ASVS Security Architecture Requirements (V1) (17)
Table 2 – OWASP ASVS Authentication Requirements (V2) (18)
Table 3 – OWASP ASVS Session Management Requirements (V3) (19)
Table 4 – OWASP ASVS Access Control Requirements (V4) (21)
Table 5 – OWASP ASVS Input Validation Requirements (V5) (22)
Table 6 – OWASP ASVS Output Encoding/Escaping Requirements (V6) (23)
Table 7 – OWASP ASVS Cryptography Requirements (V7) (24)
Table 8 – OWASP ASVS Error Handling and Logging Requirements (V8) (25)
Table 9 – OWASP ASVS Data Protection Requirements (V9) (26)
Table 10 – OWASP ASVS Communication Security Requirements (V10) (27)
Table 11 – OWASP ASVS HTTP Security Requirements (V11) (29)
Table 12 – OWASP ASVS Security Configuration Requirements (V12) (29)
Table 13 – OWASP ASVS Malicious Code Search Requirements (V13) (30)
Table 14 – OWASP ASVS Internal Security Requirements (V14) (31)
Table 15 – OWASP ASVS Report Verification Results Contents (33)
Introduction
The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem, because the most effective approaches to application security include improvements in all of these areas. We can be found at https://www.doczj.com/doc/ac6765311.html,.
OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, cost-effective information about application security. OWASP is not affiliated with any technology company, although we support the informed use of commercial security technology. Similar to many open-source software projects, OWASP produces many types of materials in a collaborative, open way. The OWASP Foundation is a not-for-profit entity that ensures the project’s long-term success.
The primary aim of the OWASP Application Security Verification Standard (ASVS) Project is to normalize the range in the coverage and level of rigor available in the market when it comes to performing Web application security verification using a commercially-workable open standard. The standard provides a basis for testing application technical security controls, as well as any technical security controls in the environment, that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection.3 This standard can be used to establish a level of confidence in the security of Web applications.
Approach
The OWASP ASVS defines verification and documentation requirements that are grouped on the basis of related coverage and level of rigor. The Standard defines four hierarchical levels (e.g. Level 2 requires more coverage and rigor than Level 1) as depicted in the figure below.
Figure 1 – OWASP ASVS Levels
3 For more information about common Web application vulnerabilities, see the OWASP Top Ten (OWASP, 2007).
Web application security verification is performed from a logical point of view by following (or attempting to follow) paths into and out of a targeted application (called the Target of Verification or TOV) and performing analysis along those paths. More complex applications typically take more time to analyze resulting in longer and more costly verifications. Lines of code are not the only factors that determine the complexity of an application – different technologies will typically require different amounts of analysis. Simple applications may include for example libraries and frameworks. Applications of moderate complexity may include simple Web 1.0 applications. Complex applications may include Web 2.0 applications and new/unique Web technologies.
ASVS defines constituent components for Levels 1 and 2 (e.g. verification at Level 1 requires meeting both Level 1A and 1B requirements). For example, applications may claim compliance to either Level 1A or 1B instead of Level 1, but making such claims is weaker than claiming Level 1. Verification and documentation requirements are defined in this Standard using three types of requirements: High-Level requirements, Detailed requirements, and Reporting requirements. The High-Level requirements define the overall application implementation and verification requirements. The Detailed requirements define low-level application implementation and verification requirements (i.e., specific items to verify). The Reporting requirements define how the results of performing an application verification according to the OWASP ASVS must be documented. OWASP provides numerous resources, including ASVS, to help organization’s develop and maintain secure applications. The OWASP ASVS, OWASP Contract Annex,4 and OWASP ESAPI5 can be used to support your Software Development Life Cycle (SDLC) as depicted in the figure below.
Figure 2 – One way to introduce verification as an activity into your SDLC6
4 For information about how to specify an ASVS level in a contract, see the OWASP Contract Annex.
5 For more information about how to ESAPI-Enable (ES-Enable) your application, see the OWASP ESAPI project (OWASP 2009).
6 For more information about introducing security-related activities into your existing SDLC, see the OWASP CLASP (OWASP 2008) or OWASP SAMM Projects (OWASP 2009).
Acknowledgements
We thank the OWASP Foundation for sponsoring the OWASP Application Security Verification
Standard Project during the OWASP Summer of Code 2008.
Project Lead: 7Mike Boberski (Booz Allen Hamilton)
Authors: 8Mike Boberski (Booz Allen Hamilton), Jeff Williams
(Aspect Security), Dave Wichers (Aspect Security)
Project
Sponsors:
Acknowledgement is given for the contributions of: Pierre Parrend, who acted as an OWASP Summer
of Code 2008 Reviewer; Andrew van der Stock (Aspect Security); Nam Nguyen (Blue Moon
Consulting); John Martin (Boeing); Gaurang Shah (Booz Allen Hamilton); Theodore Winograd (Booz
Allen Hamilton); Stan Wisseman (Booz Allen Hamilton); Barry Boyd (CGI Federal); Steve Coyle (CGI
Federal); Paul Douthit (CGI Federal); Ken Huang (CGI Federal); Dave Hausladen (CGI Federal);
Mandeep Khera (Cenzic); Scott Matsumoto (Cigital); John Steven (Cigital); Stephen de Vries
(Corsaire); Dan Cornell (Denim Group); Shouvik Bardhan (Electrosoft), Dr. Sarbari Gupta (Electrosoft); Eoin Keary (Ernst & Young); Richard Campbell (Federal Deposit Insurance
Corporation); Matt Presson (FedEx); Jeff LoSapio (Fortify Software); Liz Fong (National Institute of
Standards and Technology); George Lawless (Noblis); Dave van Stein (ps_testware); Terrie Diaz
(SAIC); Ketan Dilipkumar Vyas (Tata Consultancy Services); Bedirhan Urgun (TURKCELL); Dr. Thomas
Braun (United Nations); Colin Watson (Watson Hall); Jeremiah Grossman (WhiteHat Security); and
finally, thanks are given to the application security verification community and others interested in
trusted Web computing for their enthusiastic advice and assistance throughout this effort.
7 Email: mike.boberski@https://www.doczj.com/doc/ac6765311.html,
8 Email: jeff.williams@https://www.doczj.com/doc/ac6765311.html,, dave.wichers@https://www.doczj.com/doc/ac6765311.html,
Application Security Verification Levels
The ASVS defines four levels of verification that increase in both breadth and depth as one moves up the levels. The breadth is defined in each level by a set of security requirements that must be addressed. The depth of the verification is defined by the approach and level of rigor required in verifying each security requirement. Tools are an important part of every ASVS level. At higher
levels in ASVS, the use of tools is encouraged. But to be effective, the tools must be heavily tailored and configured to the application and framework in use. And, at all levels, tool results must be manually verified.
It is a verifier’s responsibility to determine if a TOV meets all of the requirements at the level
targeted by a review. If the application meets all of the requirements for that level, then it can be considered an OWASP ASVS Level N application, where N is the verification level that application complied with. If the application does not meet all the requirements for a particular level, but does meet all the requirements for a lower level of this standard, then it can be considered to have passed the lower level of verification. This standard uses the term the ‘verifier’ to indicate the person or team that is reviewing the application against these requirements. The specification for an application may require OWASP ASVS Level N, but it could also include other additional detailed requirements such as from a higher ASVS level. For example, a financial organization may have a lower-risk application verified to OWASP ASVS Level 2 but may also want verification that no malicious code (see V13, Level 4 only) has been included. Other organization or business requirements could apply, such as compliance with particular information security policies and regulations.
Level 1 – Automated Verification
Level 1 (“Automated Verification”) is typically appropriate for applications where some confidence in the correct use of security controls is required. Threats to security 9 will typically be viruses and worms (targets are chosen indiscriminately through wide scans and impact the most vulnerable). The scope of verification includes code that was developed or modified in order to create the application.
In Level 1, the verification involves the use of automated tools augmented with manual verification. This level only provides partial application security verification coverage. The manual verification is not intended to make the application security verification performed at this level complete, only to verify that each automated finding is correct and not a false positive.
There are two constituent components for Level 1. Level 1A is for the use of automated application vulnerability scanning (dynamic analysis) tools, and Level 1B is for the use of automated source code scanning (static analysis) tools. Verification efforts may use either of these components individually, or may perform a combination of these approaches to achieve a complete Level 1 rating. The structure of these levels is depicted in the figure below.
While it may be determined that an application meets either Level 1A or 1B, neither of these levels alone provide the same levels of rigor or coverage as an application that meets Level 1. An application that meets Level 1 must meet both Level 1A and 1B requirements.
9
For more information about identifying risks and estimating risks associated with vulnerabilities, see the OWASP Testing Guide (OWASP, 2008).
There is no verification level 0. Also, to earn a level, vulnerabilities must be remediated (or mitigated), and the application re-verified.
Figure 3 – OWASP ASVS Levels 1, 1A, and 1B
The following are the minimal high-level requirements for Level 1, 1A, or 1B applications: Verification Scope
L1.1 The scope of the verification includes all code that was developed or modified in order to create the application.
Security Control Behavior Requirements
None There are no requirements for how application security controls make decisions at Level 1. Security Control Use Requirements
None There are no requirements for where application security controls are used within the application at Level 1.
Security Control Implementation Requirements
None There are no requirements for how the application security controls are built at Level 1. Security Control Verification Requirements
L1.2 Dynamically scan the application according to the Level 1A requirements in the “Detailed Verification Requirements” section.
L1.3 Perform source code scanning on the application according to the Level 1B requirements in the “Detailed Verification Requirements” section.
Requirements at Level 1 that allow the use of either verification technique only have to be verified with one technique. In addition, if the verifier’s selected tool suite does not have the capability to verify a specified verification requirement, the verifier can perform manual verification to fill this gap.1011
10 For more information about performing manual verification by performing manual penetration testing, see the OWASP Testing Guide (OWASP, 2008).
11For more information about performing manual verification by performing a manual code review, see the OWASP Code Review Guide (OWASP, 2008).
Reporting Requirements
L1.4 Create a verification report that details the application’s security architecture by listing its components, and includes the results of the verification according to the requirements in
the “Verification Reporting Requirements” section.
At Level 1, application components may be defined in terms of either individual or groups of source files, libraries, and/or executables, as depicted in the figure below. At Level 1, the list need not be sorted or otherwise organized other than identifying which components are part of the application, and which components are part of the IT environment. The application can then be treated as groups of components within a single monolithic entity. The path or paths a given end user request may take within the application do not need to be identified and documented.
Figure 4 – OWASP ASVS Level 1 Security Architecture Example
Level 1A – Dynamic Scan (Partial Automated Verification)
Dynamic Scanning Security Control Verification Requirements
Dynamic scanning (also known as “application vulnerability scanning”) consists of using automated tools to access application interfaces, while the application is running, in order to detect vulnerabilities in the application’s security controls. Note that this is not sufficient to verify the correct design, implementation, and use of a security control, but is acceptable verification at Level 1. The scope of verification is defined by this Level’s security architecture requirements.
L1A.1 Dynamically scan the application according to the Level 1A requirements specified in the “Detailed Verification Requirements” section.
L1A.2 Verify all dynamic scan results using either manual application penetration testing or code review. Unverified automated results are not considered to provide any assurance and are
not sufficient to qualify for Level 1.
Multiple instances of a particular type of vulnerability that can be traced to a single root cause should be combined into a single finding if the scanning tool does not already do so.
Level 1B – Source Code Scan (Partial Automated Verification)
Source Code Scanning Security Control Verification Requirements
Source code scanning (also known as “static analysis”) consists of using automated tools to search through the application source code to find patterns that represent vulnerabilities. Note that this is not sufficient to verify the correct design, implementation, and use of a security control, but is acceptable verification at Level 1. The scope of verification is defined by this Level’s security architecture requirements.
L1B.1 Perform source code scanning on the application according to the Level 1B requirements specified in the “Detailed Verification Requirements” section.
L1B.2 Verify all source code scan results using either manual application penetration testing or code review. Unverified automated results are not considered to provide any assurance and are not sufficient to qualify for Level 1.
Multiple instances of a particular type of vulnerability that can be traced to a single root cause should be combined into a single finding if the code analysis tool does not already do so.
Level 2 – Manual Verification
Level 2 (“Manual Verification”) is typically appropriate for applications that handle personal transactions, conduct business-to-business transactions, process credit card information, or process personally identifiable information. Level 2 provides some confidence in the correct use of security controls and confidence that the security controls are working correctly. Threats to security will typically be viruses, worms, and unsophisticated opportunists such as attackers with professional or open source attack tools. The scope of verification includes all code developed or modified for the application as well as examining the security of all third party components that provide security functionality for the application. There are two constituent components for Level 2, as depicted in the figure below.
Figure 5 – OWASP ASVS Levels 2, 2A, and 2B
While it may be determined that an application meets either Level 2A or 2B, neither of these levels alone provide the same levels of rigor or coverage as Level 2. Further, while Level 2 is a superset of Level 1, there is no requirement to run an automated tool to meet the Level 2 requirements. Instead, the verifier has the option of using just manual techniques for all requirements. If automated tool results are available, the verifier may use them to support the analysis. However, even passing a requirement at Level 1 does not automatically indicate passing the same requirement
at Level 2. This is because automated tools do not provide sufficient evidence that the positive requirement has been met.
Manual techniques are still assumed to employ the use of tools. This can include the use of any kind of security analysis or testing tool, including the automated tools that are used for Level 1 verifications. However, such tools are simply aids to the analyst to find and assess the security controls being verified. Such tools may or may not contain logic to automatically detect application vulnerabilities.
The following are the minimal high-level requirements for Level 2, 2A, or 2B applications: Verification Scope
L2.1 The scope of the verification includes all code that was developed or modified in order to create the application. This requirement was introduced at Level 1.
L2.2 The scope of the verification includes the code for all third-party framework, library, and service security functionality that is invoked by or supports the security of the application.
This is a new requirement at Level 2.
Security Control Behavior Requirements
L2.3 Verify that all technical security controls that perform security checks make decisions using
a whitelist approach. This is a new requirement at Level 2.
L2.4 Verify that all security controls that perform security checks and security controls that result in security effects cannot be bypassed according to the Level 2A and 2B requirements specified in the “Detailed Verification Requirements” section. This is a new requirement at Level 2.
Security Control Use Requirements
L2.5 Verify that all security controls are used everywhere within the application they need to be, and the implementations are centralized within the application, on the server side, according to the Level 2 requirements specified in the “Detailed Verification Requirements” section. This is
a new requirement at Level 2.
Security Control Implementation Requirements
None There are no requirements for how application security controls are built at Level 2.
Security Control Verification Requirements
L2.6 Perform manual application penetration testing on the application according to the Level 2A requirements specified in the “Detailed Verification Requirements” section. This is a new
requirement at Level 2.
L2.7 Perform a manual source code review on the application according to the Level 2B requirements specified in the “Detailed Verification Requirements” section. This is a new
requirement at Level 2.
Requirements at Level 2 that allow the use of either verification technique only have to be verified with one technique.
The verifier may include automated scanning or code analysis as part of their verification effort at Level 2, but automated verification cannot be used in place of the manual review required for each Level 2 requirement. If the scan results help the verifier perform their work more quickly or
augment the results of the manual portion of the review, they can certainly be used to assist in performing a Level 2 verification.
Reporting Requirements
L2.8 Create a verification report that describes the application’s security architecture by grouping its components into a high-level architecture, and includes the results of the
verification according to the requirements in the “Verification Reporting Requirements”
section. This augments the reporting requirement introduced at Level 1.
At Level 2, application components may be defined in terms of either individual or groups of source files, libraries, and/or executables that are organized into a high-level architecture (for example Model-View-Controller (MVC) components, business function components, and data layer components). For example, the diagram below depicts an application that consists of a server application, an application server application, custom code, libraries, and a database application that are grouped according to an MVC architecture. At Level 2, the path or paths a given end user request may take within the application must be documented, as depicted in the figure below. However, not all such paths must be examined.
Figure 6 – OWASP ASVS Level 2 Security Architecture Example
Level 2A – Security Test (Partial Manual Verification)
Manual Application Penetration Testing Security Control Verification Requirements Manual application security testing consists of creating dynamic tests to verify an application’s proper design, implementation, and use of security controls. The scope of verification is defined by this Level’s security architecture requirements.
L2A.1 Perform manual application security testing on the application according to the Level 2A requirements specified in the “Detailed Verification Requirements” section. This is a new
requirement at Level 2.
Where appropriate, the verifier may use sampling to establish the effective use of a security control. The verifier may choose to document a vulnerability pattern that will allow developers to confidently find and fix all instances of the pattern in the software baseline. Multiple instances of a vulnerability pattern that can be traced to a single root cause should be combined into a single finding.
Level 2B – Code Review (Partial Manual Verification)
Manual Code Review Security Control Verification Requirements
Manual code review consists of human searching and analysis of the application source code in order to verify the application’s design, implementation, and proper use of security controls. Such analysis is expected to be tool assisted, but could simply involve commonly available tools such as a source code editor or IDE. The scope of verification is defined by this Level’s security architecture requirements.
L2B.1 Perform a manual code review on the application according to the Level 2B requirements specified in the “Detailed Verification Requirements” section. This is a new requirement at Level 2.
Where appropriate, the verifier may use an appropriate sampling method to establish the effective use of a security control. The verifier may choose to document a vulnerability pattern that will allow developers to confidently find and fix all instances of the vulnerability pattern in the software baseline. Multiple instances of a vulnerability pattern that can be traced to a single root cause should be combined into a single finding.
Level 3 – Design Verification
Level 3 (“Design Verification”) is typically appropriate for applications that handle significant business-to-business transactions, including those that process healthcare information, implement business-critical or sensitive functions, or process other sensitive assets. Threats to security will typically be viruses and worms, opportunists, and possibly determined attackers (skilled and motivated attackers focusing on specific targets using tools including purpose-built scanning tools). The scope of verification includes all code developed or modified for the application, as well as examining the security of all third party components that provide security functionality for the application. Level 3 ensures that security controls themselves are working correctly, and that security controls are used everywhere within the application they need to be used to enforce application-specific policies. Level 3 is not broken into multiple components, as depicted in the figure below.
Figure 7 – OWASP ASVS Level 3
The following are the minimal high-level requirements for Level 3 applications:
Verification Scope
L3.1 The scope of the verification includes all code that was developed or modified in order to create the application. This requirement was introduced at Level 1.
L3.2 The scope of the verification includes the code for all third-party framework, library, and service security functionality that is invoked by or supports the security of the application.
This requirement was introduced at Level 2.
L3.3 The scope of the verification includes the code for all third-party frameworks, libraries, and services associated with the application. This is a new requirement at Level 3.
Security Control Behavior Requirements
L3.4 Verify that all security controls that perform security checks make decisions using a whitelist approach. This requirement was introduced at Level 2.
L3.5 Verify that all security controls that perform security checks and security controls that result in security effects cannot be bypassed according to the Level 3 requirements
specified in the “Detailed Verification Requirements” section. This requirement was
introduced at Level 2.
Security Control Use Requirements
L3.6 Verify that all security controls are used everywhere within the application they need to be, and the implementations are centralized within the application, on the server side, according to the Level 3 requirements specified in the “Detailed Verification Requirements” section. This
requirement was introduced at Level 2.
Security Control Implementation Requirements
None There are no requirements for how application security controls are built at Level 3.
Security Control Verification Requirements
L3.7 Manually verify the application according to the Level 3 requirements specified in the “Detailed Verification Requirements” section. This augments the manual verification
requirements introduced at Level 2.
L3.8 Document a security architecture and use it to verify the proper design and use of all security controls by performing threat modeling. This is a new requirement at Level 3.
Reporting Requirements
L3.9 Create a verification report that describes the application’s security architecture by grouping its components into a high-level architecture that includes threat modeling
information, and includes the results of the verification according to the requirements in
the “Verification Reporting Requirements” section. This augments the reporting
requirement from Level 2.
At level 3, application components may be defined in terms of either individual or groups of source files, libraries, and/or executables that are grouped into a high-level architecture (for example MVC components, business function components, and data layer components). At Level 3, supporting threat modeling information about threat agents and assets must additionally be provided. The path or paths a given end user request may take through a high-level view of the application must be documented, as depicted in the figure below. At Level 3, all potential paths through the high-level view of the application must be examined.
Figure 8 – OWASP ASVS Level 3 Security Architecture Example12
12 Dollar signs indicate assets in the diagram.
Level 4 – Internal Verification
Level 4 (“Internal Verification”) is typically appropriate for critical applications that protect life and
safety, critical infrastructure, or defense functions. Level 4 may also be appropriate for applications
that process sensitive assets. Level 4 ensures that security controls themselves are working correctly, that security controls are used everywhere within the application they need to be used to
enforce application-specific policies, and that secure coding practices were followed. Threats to
security will be from determined attackers (skilled and motivated attackers focusing on specific
targets using tools including purpose-built scanning tools). The scope of verification expands beyond
the scope of Level 3 to include all code used by the application. Level 4 is not broken out into
constituent components, as depicted in the figure below.
Figure 9 – OWASP ASVS Level 4
The following are the minimal high-level requirements for Level 4 applications:
Verification Scope
L4.1 The scope of the verification includes all code that was developed or modified in order to create the application. This requirement was introduced at Level 1.
L4.2 The scope of the verification includes the code for all third-party framework, library, and
service security functionality that is invoked by or supports the security of the application.
This requirement was introduced at Level 2.
L4.3 The scope of the verification includes the code for all third-party frameworks, libraries,
and services associated with the application. This requirement was introduced at Level 3.
L4.4 The scope of the verification includes all remaining code associated with the application,
including frameworks, libraries, runtime environments, development tools, build tools, and
deployment tools. The scope does not include the code for platform software, such as an
application server, database server, virtual machine, or operating system, that has received
a substantial amount of public scrutiny. This is a new requirement at Level 4.
Security Control Behavior Requirements
L4.5 Verify that all security controls that perform security checks make decisions using a whitelist (“positive”) approach. This requirement was introduced at Level 2.
L4.6 Verify that all security controls that perform security checks and security controls that
result in security effects cannot be bypassed according to the Level 4 requirements
specified in the “Detailed Verification Requirements” section. This requirement was
introduced at Level 2.
Security Control Use Requirements
L4.7 Verify that all security controls are used everywhere within the application they need to be, and that the implementations are centralized within the application, on the server side,
according to the Level 4 requirements specified in the “Detailed Verification Requirements”
section. This requirement was introduced at Level 3.
Security Control Implementation Requirements
L4.8 Verify that the application does not contain any malicious code according to the Level 4 requirements specified in the “Detailed Verification Requirements” section. This is a new
requirement at Level 4.
Security Control Verification Requirements
L4.9 Manually verify the application against the Level 4 requirements specified in the “Detailed Verification Requirements” section. This augments the requirement from Level 3.
L4.10 Document a security architecture and use it to verify the proper design and use of all security controls by performing threat modeling. This requirement was introduced at Level
3.
L4.11 Manually review all code developed or modified for this application for malicious code13 according to the Level 4 requirements specified in the “Detailed Verification Requirements”
section. This is a new requirement at Level 4.
Reporting Requirements
L4.12 Create a verification report that describes the application’s security architecture according to the Level 3 requirements, which encompasses all application code, and includes the
results of the verification according to the requirements in the “Verification Reporting
Requirements” section. This augments the reporting requirement from Level 3.
At Level 4, the application’s architecture shall be captured as required at Level 3. Further, Level 4 requires that all application code, including code not explicitly examined, be identified as part of the application definition, as depicted in the figure below. This code must include all libraries, frameworks, and supporting code that the application relies on. Previous verifications of these components can be reused as part of another verification effort. Platform code, such as the operating system, virtual machine, or core libraries issued with a virtual machine environment, Web server, or application server are not included in Level 4. For example, libraries associated with the Java runtime would not need to be assessed at Level 4.
13 Malicious code is not the same as malware. See the glossary definition of malicious code.
Figure 10 – OWASP ASVS Level 4 Unexamined Code Example
Requirement Interpretations and Precedents
The OWASP ASVS is a living document. If you are performing an application security verification according to this standard, then you should always review the articles that can be found on the OWASP ASVS project page at the following location:
https://www.doczj.com/doc/ac6765311.html,/index.php/ASVS#Articles_Below_-_More_About_ASVS_and_Using_It . The articles on the OWASP ASVS project page provide requirement clarifications, requirement verdict precedents, and helpful hints.
Detailed Verification Requirements
This section of the OWASP Application Security Verification Standard (ASVS) defines detailed verification requirements that were derived from the high-level requirements for each of the verification levels defined in this standard. Each section below defines a set of detailed verification requirements grouped into related areas.
The ASVS defines the following security requirements areas:
V1. Security Architecture
V2. Authentication
V3. Session Management
V4. Access Control
V5. Input Validation
V6. Output Encoding/Escaping
V7. Cryptography
V8. Error Handling and Logging
V9. Data Protection
V10. Communication Security
V11. HTTP Security
V12. Security Configuration
V13. Malicious Code Search
V14. Internal Security
For each of these areas, the requirements that must be met at each of the verification levels listed below are specified:
Level 1: Automated Verification
Level 1A – Dynamic Scan (Partial Automated Verification)
Level 1B – Source Code Scan (Partial Automated Verification)
Level 2: Manual Verification
Level 2A – Security Test (Partial Manual Verification)
Level 2B – Code Review (Partial Manual Verification)
Level 3: Design Verification
Level 4: Internal Verification
1.目的：建立设备清洗验证管理规程，以规设备清洗的验证工作。 2.围：本规程适用于安装试用前后设备、大修后设备、全部生产完成后设备清洁的验证。 3.职责：公司质量负责人、验证小组成员及各部门负责人对本规程的实施负责。 4.依据：《药品生产质量管理规》（2010年版）附录：确认与验证 5.程序 5.1清洁验证定义 有文件和记录证明所批准的清洁规程能有效清洁设备，使之符合药品生产的要求。5.1.1清洁验证注意事项 清洁验证应综合考虑设备使用情况、所使用的清洁剂和消毒剂、取样法和位置以及相应的取样回收率、残留物的性质和限度、残留物检验法的灵敏度等因素。 5.1.2清洁验证的一般要求 清洁验证是通过文件证明清洁程序有效性的活动，目的是确保产品不会受到来自于同一设备上生产的其他产品的残留物、清洁剂以及微生物污染； 为了证明清洁程序的有效性，清洁验证的次数应当根据风险评估确定，通常应至少执行连续三个成功的清洁循环；清洁验证计划完成需要一定的时间，验证过程中每个批次后的清洁效果需及时进行确认；根据清洁验证结果，必要时，在清洁验证后应当对设备的清洁效果进行持续确认。
对于专用设备，清洁验证可以不必对活性成分进行考察，但必须考虑清洁剂残留以及潜在的微生物污染等因素，对于一些特殊的产品，还应考察降解产物； 对于没有与药物成分接触的设备，清洁验证可以不必对活性成分进行考察，但必须考虑清洁剂残留及微生物污染等因素； 清洁验证中需对下列放置时间进行考察，进而确定常规生产中设备的放置时间： ①设备最后一次使用与清洁之间的最大时间间隔（“待清洁放置时间”） ②设备清洁后至下次使用的最大时间间隔（“清洁后放置时间”） ③当采用阶段性生产组织式时，应当综合考虑阶段性生产的最长时间和最大批次 数量，以作为清洁验证的评价依据（最长连续生产期） 5.2清洁验证流程 清洁验证前提条件 ①清洁规程已经批准，包括关键清洁程序的参数围
纺织企业安全生产标准化评定标准 考评说明 1.本评定标准适用于棉纺、织造、化纤、染整、成衣等纺织企业，其他纺织企业参照执行。 2.本评定标准共13项考评类目、47项考评项目和143条考评容。 3.在本评定标准的“自评/评审描述”列中，企业及评审单位应根据“考评容”和“考评办法”的有关要求，针对企业实际情况，如实进行扣分点说明、描述，并在《自评扣分点及原因说明汇总表》（见附表）中逐条列出。 4.本评定标准中累计扣分的，直到该考评容分数扣完为止，不得出现负分。有需要追加扣分的，在该考评类目进行扣分，也不得出现负分。 5.在 6.2设备设施运行管理部分中“专用设备（一）至（五）”分别列举了棉纺、织造、化纤、染整、成衣等五类专用设备，每类专用设备均为40分，参评企业根据各自生产性质选择一类进行评定，其他类别不再评定、分数不计入总分。 在7.1生产现场管理和生产过程控制部分中“生产过程控制（一）至（五）”分别列举了棉纺、织造、化纤、染整、成衣等五类生产过程控制要求，每类生产过程控制均为40分，参评企业根据各自生产性质选择一类进行评定，其他类别不再评定、分数不计入总分。 6.本评定标准共计1000分。最终评审评分换算成百分制，换算公式如下： 最后得分采用四舍五入，取小数点后一位数。
7.标准化等级分为一级、二级和三级，一级为最高。评定所对应的等级须同时满足评审评分和安全绩效等要求，取最低的等级来确定标准化等级（见下表）。
纺织企业安全生产标准化评定标准 自评/评审单位： 自评/评审时间：从年月日到年月日自评/评审组组长：自评/评审组主要成员： .. .. .. ..
清洁验证管理规程 你的签名表明你已清楚了解本文件及附件内容，充分理解并认可本文件的所有条 任何对本文件及其附件的目的、内容或标准进行的改变或修正都必须起到改善的作用，并详细记录文件 的修订及变更历史（详见变更记录），并且在执行以前必须取得批准，下表仅记
1. 目的 用于规范广西双蚁药业有限公司清洁验证工作管理工作。 2. 范围 适用于广西双蚁药业有限公司清洁验证的实施与管理。 3. 术语或定义 N/A 4. 职责 4.1 生产车间工艺员负责制定、修订和培训设备清洁方案。 4.2 生产操作人员负责按照批准的清洁程序对设备进行清洁。 4.3 QC 人员负责制定清洁验证相关的分析方法和清洁验证过程中的取样工作。 4.4 QA 人员负责清洁验证方案及报告的审核，负责清洁验证过程中偏差的处理及变更控制。 5. 程序 5.1 概述 清洁验证实际就是对清洗标准操作规程的验证，通过验证建立合适的设备清洁标准操作规程。 清洁验证的目的是证明所采用的清洁方法确能避免产品的交叉污染，微生物污染以及清洁后残 留的污染，使之达到可接受限度标准。 5.2 清洁验证的步骤 5.2.1 列出待进行清洁验证的设备所生产的一组产品。 5.2.2 选择参照产品。在所生产的一组产品中，选择最难清洁(即溶解度最小)的产品作参照产品。 相对于辅料而言，活性成分的残留物对下批产品的质量，疗效和安全性有更大的
5.2.3 选择设备最难清洗部位和取样点。凡是死角、清洁剂不易接触的部位——如带密封垫圈的管道连接处，压力、流速迅速变化的部位如有歧管或岔管处，管径由小变大处，容易吸附残留物的部位如内表面不光滑处等，均应视为最难清洗部位。取样点应包括各类最难清洗部位。 5.2.4 选择最不利清洗条件的参数 5.2.4.1 一组产品中最小NOEL=活性成分最小LAD／40（μｇ/60kg 体重） 其中：NOEL～活性成分的无显著影响值； LAD～每60kg 体重最小有效剂量； 40(即4×10) ～总体安全系数。 5.2.4.2 一组产品中最大口服日剂量(ml／g 或mｇ/日)。 5.2.4.3 一组产品中最小批量(mg 或ml)。 5.2.4.4 棉签取样面积(25cm2／每个棉签)。 5.2.4.5 设备内表面积(或与物料直接接触的总面积) (cm2)。 5.2.4.6 取样有效性(一般取50％，即假定棉签所取样品有50％的量被洗脱出来)。 5.2.4.7 冲洗溶剂的体积(ml)。 5.2.5 化学验证及可接受标准限度。清洗效果的最终评价根据是产品活性成分即主药及洗涤剂的残留量、微生物限度。 5.2.5.1 企业界普遍接受的限度标准基于以下原则： （1）生物活性限度：任何产品不能受到前一品种带来的超过其0.001 的日剂量的污染。 (2)分析方法客观能达到的能力：污染不能超过10PPm。 (3)微生物限度：视取样方法不同而异。棉签法取样可接受标准≤50CFU/棉签，最终冲洗水取样可接受标准≤25CFU／ml。 (4)以目检为依据的限度：不得有可见的残留物，假定为4μg/cm2(100μ g/4in2)，且不得有残留气味。 5.2.5.2 所选择的参照产品生产结束后，按规定的清洁程序清洗设备，目检无可
工贸企业安全生产标准化基本规范评分细则 考评说明 1.本评分细则适用于冶金、有色、建材、机械、轻工、纺织、烟草、商贸等行业企业（以下统称冶金等工贸企业）根据《企业安全生产标准化基本规范》(AQ/T9006-2010)开展安全生产标准化自评、申请、外部评审及各级安全监管部门监督审核等相关工作。冶金等工贸企业已有专业评定标准的，优先适用专业评定标准。 2.本标准共有13项一级要素、42项二级要素及194条企业达标标准。 3.在评分细则中的自评/评审描述列中，企业及评审单位应根据评分细则的有关要求，针对企业实际情况，如实进行得分及扣分点说明、描述，并在自评扣分点及原因说明汇总表（见附表）中逐条列出。 4.本评定标准中累计扣分的，均为直到该考评内容分数扣完止，不出现负分。有特别说明扣分的（在考评方式中加粗的内容），在该类目内进行扣分。 5.本评定标准共计1000分，最终标准化得分换算成百分制。换算公式如下： 标准化得分（百分制）=标准化工作评定得分÷（1000－不参与考评内容分数之和）×100。最后得分采用四舍五入，取小数点后一位数。 6.标准化等级共分为一级、二级、三级，其中一级为最高。评定所对应的等级须同时满足标准化得分和安全绩效等要求，取最低的等级来确定标准化等级（见下表）。
7.冶金等工贸企业安全生产标准化考评程序、有效期、等级证书和牌匾等按照《全国冶金等工贸企业安全生产标准化考评办法》（安监总管四〔2011〕84号）的有关要求执行。
冶金等工贸企业安全生产标准化基本规范评分表自评/评审单位： 自评/评审时间：从年月日到年月日 标准相关~
标准相关~
企业安全生产标准化建设流程 一、什么是安全生产标准化？ 是指通过建立安全生产责任制，制定安全管理制度和操作规程，排查治理隐患和监控重大危险源，建立预防机制，规范生产行为，使各生产环节符合有关安全生产法律法规和标准规范的要求，人、机、物、环处于良好的生产状态，并持续改进，不断加强企业安全生产规范化建设。 安全生产标准化体现了“安全第一、预防为主、综合治理”的方针和“以人为本”的科学发展观，强调企业安全生产工作的规范化、科学化、系统化和法制化，强化风险管理和过程控制，注重绩效管理和持续改进，符合安全管理的基本规律，代表了现代安全管理的发展方向，是先进安全管理思想与我国传统安全管理方法、企业具体实际的有机结合，有效提高企业安全生产水平，从而推动我国安全生产状况的根本好转。 主要内容包括目标、组织机构和职责、安全生产投入、法律法规与安全管理制度、教育培训、生产设备设施、作业安全、隐患排查和治理、重大危险源监控、职业健康、应急救援、事故的报告和调查处理、绩效评定和持续改进等13个方面。 企业安全生产标准化建设流程包括策划准备及制定目标、教育培训、现状梳理、管理文件制修订、实施运行及整改、企业自评、评审申请、外部评审等八个阶段。 二、建设流程？ 1、策划准备及制定目标 企业需成立安全生产标准化建设小组，并明确目标，全面保障安全生产标准 化的建设落实。 2、教育培训 安全生产标准化建设需要全员参与。教育培训要解决的就是领导层的认识以 及执行层的理解。
3、现状梳理 对企业应安全管理情况、现场设备设施状况进行全面摸底，并根据企业自身 情况及时调整目标，开展建设。 4、管理文件制修订 结合现状摸底所发现的问题，准确判断管理文件亟待加强和改进的薄弱环 节，并提出有关文件的制修订计划。 5、实施运行及整改 企业要在日常工作中依据制修定的管理文件进行实际运行。并根据运行情况 及时进行整改及完善。 6、企业自评 经过一段时间的运行，应依据评定标准，开展自评工作。并结合发现的问题 进行整改，着手准备评审申请材料。 7、评审申请 企业要通过《安全生产标准化达标信息管理系统》完成评审申请工作。并与 相关交通安全监管部门或评审组织单位联系。 8、外部评审 接受外部评审单位的评审，针对问题，形成整改计划，及时进行整改，并配 合评审单位上报有关评审材料。 三、各阶段工作内容： 1、策划准备及制定目标 策划准备阶段首先要成立领导小组，由企业主要负责人担任领导小组组长， 所有相关的职能部门的主要负责人作为成员，确保安全生产标准化建设组织保障；成立执行小组，由各部门负责人、工作人员共同组成，负责安全生产标准化建设过程中的具体问题。 制定安全生产标准化建设目标，并根据目标来制定推进方案，分解落实达标 建设责任，确保各部门在安全生产标准化建设过程中任务分工明确，顺利完成各 阶段工作目标。 关注点及注意事项
设备清洁验证方案 1.概述： 1.1 概述 ********设备是药品生产中的关键设备，对此清洁有助于消除活 性成分的交叉污染，降低或消除微生物对药剂的污染。因此，制 定切实可行清洁操作程序，并对它进行验证是保证产品质量，防 止交叉污染的有效措施。本验证是按照验证方案进行，在生产结 束后按清洁规程对********设备进行清洁，按取样规程取样并进 行检验，分析其结果是否能达到预定标准来确认清洁规程的有效 性。 1.2 使用设备及生产品种 使用********设备，设备技术参数见附件1。我们在试生产期间生产了********产品，产品特性见附件2。 2. 验证范围： 本验证方案适用于口服固体车间、软膏车间、中药提取车间以及 纱布车间所有设备的清洁效果验证。 3. 验证实施时间：年月日至年月日。 4. 验证部门及职责： 4.1 验证领导小组： 4.1.1.负责验证方案的审批。 4.1.2.负责验证的协调工作，以保证本方案规定项目的顺利实施。
4.1.3.负责验证数据及结果的审核。 4.1.4.负责验证报告的审核。 4.1. 5.负责发放验证证书。 4.2 设备动力部 4.2.1.负责收集各项验证，试验记录，起草验证报告，报验证小组。4.2.2.负责设备的维护保养。 4.3 质量管理部 4.3.1.负责验证所需的标准品、样品、试剂、试液等的准备。 4.3.2负责各种理化检验、微生物检验的准备，取样及调试工作。 4.3.3负责根据结果出具检验报告单。 4.4 生产技术部 4.4.1负责制订清洁规程，并按规程清洁。 4.4.2负责根据试验结果，修改设备清洁规程。 5. 验证目的： 5.1 根据GMP的要求，必须对设备的清洁进行验证，以保证药品在生 产过程中，设备清洁后的残留不会对下一批产品的质量造成影响，证明设备按********设备清洁标准操作规程进行清洁操作后能达 到工艺要求。 5.2 为达到上述验证目的，特制定本验证方案，对********设备清洁 效果进行验证。验证过程应严格按照本方案规定的内容进行，若 因特殊原因确需变更时，应填写验证方案变更申请及批准书，报
安全生产标准化考评程序 一、安全生产标准化考评程序 1、考评申请及受理 2、考评策划及考评准备 3、考评的实施 4、纠正措施的跟踪验证 5、审批发证及考评后的监督管理 二、申请方向考评机构递交以下材料： 1、申请考评的范围 2、申请人同意遵守考评要求，提供考评所需要的信息 3、企业基本信息 4、企业安全生产情况简介,包括近两年中的事故发生情况 5企业安全标准化系统的运行情况(自评报告) 6、企业安全标准化系统文件（电子版本、文本各一份） 三、申请受理的一般条件： 1、登记注册、具备有效的法人资格,或具备二级或委托方法人资格 2、生产许可证和安全生产许可证 3、建立了文件化的安全标准化系统 4、至少作过一次完整的内部自评及安全标准化绩效评估 5、系统全部要素已有效运行一遍，至少有6个月以上的运行纪录 6、县级以上安全监管部门出具的、近两年无事故证明（较大以上） 四、考评机构就申请方报送的信息和要求进行内部评审 1、考评机构的各项要求、规定明确，已形成文件并得到理解 2、考评机构与申请人之间在考评信息方面的差异得到充分的沟
通和理解 3、考评机构有能力实施对申请方的考评。 五、考评机构的准备 1、计划调度确定考评范围（系统覆盖生产活动区域） 2、委托考评组长 3、组建考评组 4、制定考评计划 5、编制考评工作文件 六、组建考评组 1、指定考评组长 2、确定考评组的规模和成员（专业分类） 3、是否需要邀请见证人员 4、制定考评计划 七、考评计划应包含的内容 1、考评目的 2、考评范围 3、考评准则 4、考评组成员 5、考评日期 6、考评日程安排 7、保密要求 8、考评要求 八、编制考评工作文件 1、考评检查表 2、考评任务分配表 3、首末次会议签到表 4、首末次会议记录表
高晶钒钛汽车板簧 GJ–AQ02-2017 安全标准化管理手册 依据标准AQ/T9006-2010 《企业安全生产标准化基本规》 受控状态：受控 版本号：A/O-A Q02 发放号： 编制： 审核： 批准： 2017-3-25发布2017-4-31实施 高晶钒钛汽车板簧发布
目录 第一章总则 第二章手册管理 第三章各类安全管理制度 第一部分基本安全生产管理制度 A1.1安全目标管理制度 A1.2安全生产目标管理责任制考核奖惩办法A2.1安全生产责任制 A2.2安全生产责任制管理制度 A2.3安全会议制度 A3.1安全生产费用提取和使用管理制度 A3.2工伤保险管理制度 A4.1法律法规规管理制度 A4.2安全生产规章制度和操作规程管理制度A4.3文件和档案管理制度 A5.1安全教育培训管理制度 A5.2特种作业人员管理制度 A6.1建设项目安全设施“三同时”管理制度A6.2生产设备设施安全管理制度 A6.3施工和检（维）修安全管理制度 A6.4生产设备设施维护保养安全管理制度 A6.5生产设备设施验收安全管理制度 A6.6生产设备设施报废安全管理制度 A6.7特种设备安全管理制度 A7.1“三违”行为检查管理制度 A7.2作业安全管理制度 A7.3现场带班安全管理制度 A7.4消防安全管理制度 A7.5警示标志和安全防护管理制度 A7.4相关方安全管理制度 A7.6变更管理制度 A8.1安全检查及隐患治理管理制度 A9.1危险物品和危险源管理制度
A9.2风险评估和控制管理制度 A10.1职业健康管理制度 A10.2劳动防护用品（具）和保健品管理制度A11.1应急管理制度 A12.1安全事故管理制度 A13.1安全绩效评定管理制度 A13.2岗位达标管理制度 第二部分其它安全生产管理制度 安全生产奖惩制度 巡回检查制度 用电管理制度 交接班制度 安全生产值班制度 外来人员及车辆管理制度 安全标准化运行自评制度 动火作业安全管理规定 高处作业安全管理规定 动土作业安全管理规定 施工作业安全管理规定 临时用电、用气安全管理规定 装卸、运输安全管理规定 危险化学品安全管理规定 应急救援器材维护制度 第四章各类操作规程 第五章安全教育 第六章安全作业证 第七章安全生产技术通则 第八章应急救援预案
2018-10-12 清洁验证管理规程 目的 确立可靠的清洁方法和程序，以防止药品在生产过程中受到污染和交叉污染。 范围 本规程适用于生产车间接触产品设备表面的清洁方法的验证管理。 责任 生产车间、生产技术部、质量部、设备动力部、供应部、生产负责人、质量负责人对本规程的实施负责。 内容 1 成立验证委员会和验证小组 1.1 成立验证委员会，明确验证委员会成员职责，质量负责人担任验证委员会组长。 1.2 验证实施部门建立验证小组，并由验证实施部门负责人担任组长组织实施验证工作。 2 清洁验证流程 2.1 申请表签批→起草方案→方案审批表签批→实施验证。 2.2 申请表签批后由验证专员编制编号，编号原则为验证方案代码CV，验证报告代码VR，验证合格证书代码VC，同一个验证方案、验证报告及合格证书编码应一一对应，XX-XX-XXXXX-X（验证文件代码-部门代码-小类码与流水号-版本号）。 2.3 方案审批表一级审核人（方案审核人）为验证小组组长，方案审批表二级审核人为验证委员会成员中相关各部门负责人。 2.4 收集验证数据→整理验证记录→起草验证报告→报告审核表签批→验证合格证签批。 2.5 报告审核表一级审核人（结果审核人）为验证小组组长，验证报告审核表二级审核人为验证委员会成员中相关各部门负责人。 2.6 验证合格证审核人为验证小组组长。 2.7 验证申请表、验证方案、验证方案审批表、验证记录、验证报告、验证报告审核表、验证合格证装订成册，统一归档至质量部验证专员处。 3 清洁验证的必要性 3.1 符合GMP要求； 3.2 降低药物交叉污染及微生物污染的风险； 3.3 保证药品安全； 3.4 延长系统或设备的使用寿命； 3.5 提高企业经济效益。 4 清洁的含义
第四节设备的清洁验证 关于清洁验证的原理及方法将在第三篇第二章详细介绍，制剂生产验证各章亦对相应设备的清洗验证要点进行介绍，可以参阅这些章节的内容。 考虑到制药设备验证的完整性，应包括设备的确认，变动控制程序、仪器仪表的校准和清洗验证。在此对设备的清洁验证从方法上作简单介绍。 设备清洗有自动清洗和人工清洗两种方法，或者两种方法的结合。 所谓清洗是从工艺设备或贮存设备中清除污染物的工艺过程，以保证设备能够安全地进行下一步的产品生产，它包括清洗、消毒和贮存。 设备清洁验证的目的是通过测试证明该设备的自动清洗程序(CIP)或人工清洗程 序能够清除设备部件上的活性药物残留物，并达到可接受的合格标准，并证明此清洁程序具有稳定性和重演性。 一、设备清洁验证中常用的术语 ①人体接触剂量限度(SEL，Subject E×posure Limit)。指一个没有药理学和毒理 学经验的人可以接触的某一药物的暴露剂量。 ②允许残留浓度(ARL，Allowable Residual Limit)．指某一设备经清洗后，其表面残留的药物(或清洁剂)的最大允许量。 ③活性成分(API，Active Pharmaceutical lngredient；或ADS，Active Drug Substance)：指在某一药物中代表效用的物质。这种物质在制造、工艺或包装过程中就变成了一种活性成分或者药物的最终成型形式。活性成分在疾病诊断、治疗、缓解、处理或预防方面提供药理上的活力或其他直接的作用，以致影响人体或动物的组织和功能。 API 在工艺制造过程中产生，如：①化学合成；②发酵；③重组DNA 或其他 生物工艺；④从自然资源上分离或取得；⑤ 其他工艺的任何组合等。对设备清洁验证来说，API 包括中间体及成品。 一般来说，SEL、ARL 的允许值应从药物安全评价部门获取。 二、验证设计 在验证取样测试时，若发现洗过的设备明显不干净，应立即停止验证，有明显的残留物存在表明现有的清洁程序是不合适的，因此必须在验证开始前重新评价清洁程序。从某种意义上来说，清洁验证就是对清洗标准操作规程的验证。 清洁验证主要是通过擦拭取样法和冲洗取样法对活性成分APl 进行测试。另外可根据日常使用的需要，增加一些其他项目的测试，如清洁剂、酸液、溶剂、消毒剂等残留量的测试。 大部分企业在设备清洗中使用的清洁剂是水(包括饮用水、纯化水和注射用水)，原因之 一就是使用化学清洁剂要作清洁剂残留量的测试，从而增加清洗的难度。 制造部门在设备清洁程序中任何关于清洁剂、溶剂、添加剂的改变必须填写变动控制表， 得到批准后执行。并非所有的设备清洁验证需做活性成分APl 的测试。根据APl 是否在特殊的清洁剂或溶剂中溶解而使设备难以清洗的程度来对APl 的浓度作 出评价o APl 允许浓度可根据公式来计 算，如果人体接触剂量限度SEL 太低无法达到时，可用替代基质来覆盖所有的 产品。 (一)验证次数
安全生产标准化流程及关注点
第一、策划准备及制定目标。 策划准备阶段首先要成立领导小组，由企业主要负责人担任领导小组组长，所有相关的职能部门的主要负责人作为成员，确保安全生产标准化建设组织保障；成立执行小组，由各部门负责人、工作人员共同组成，负责安全生产标准化建设过程中的具体问题。 制定安全生产标准化建设目标，并根据目标来制定推进方案，分解落实达标建设责任，确保各部门在安全生产标准化建设过程中任务分工明确，顺利完成各阶段工作目标。 关注点及注意事项 建设安全生产标准化需要企业最高管理者的大力支持及管理层的配合，因此需要召开安全生产标准化首次会议进行策划准备及制定相关目标。
第二、教育培训。 安全生产标准化建设需要全员参与。教育培训首先要解决企业领导层对安全生产标准化建设工作重要性的认识，加强其对安全生产标准化工作的理解，从而使企业领导层重视该项工作，加大推动力度，监督检查执行进度；其次要解决执行部门、人员操作的问题，培训评定标准的具体条款要求是什么，本部门、本岗位、相关人员应该做哪些工作，如何将安全生产标准化建设和企业日常安全管理工作相结合。 同时，要加大安全生产标准化工作的宣传力度，充分利用企业内部资源广泛宣传安全生产标准化的相关文件和知识，加强全员参与度，解决安全生产标准化建设的思想认识和关键问题。 关注点及注意事项 安全生产标准化工作强调全员、全过程、全方位、全天候监督管理原则，因此，进行全员安全生产标准化培训是安全生产标准化
工作重点内容之一。企业安全生产标准化管理办公室根据实际情况，对公司全员进行培训。 第三、现状梳理。 对照相应专业评定标准（或评分细则），对企业各职能部门及下属各单位安全管理情况、现场设备设施状况进行现状摸底，摸清各单位存在的问题和缺陷；对于发现的问题，定责任部门、定措施、定时间、定资金，及时进行整改并验证整改效果。现状摸底的结果作为企业安全生产标准化建设各阶段进度任务的针对性依据。 企业要根据自身经营规模、行业地位、工艺特点及现状摸底结果
标准操作规程 STANDARD OPERATING PROCEDURE 标 题 设备清洁方法验证标准操作规程 共5页 第1页 制定人颁发部门 GMP办公室编 号： SOP--F—006 分发部门 设备验证小组、质量保证部新订 √替代 审核人批准人生效日期年月日 目 的：通过科学的方法采集足够的数据，以证明按规定方法(清洁规程)清洁后的设备，能始终如一地达到预定的清洁标准。 适用范围：所有工艺设备清洁方法的验证。 贵 任 者：生产车间、质量保证部 程 序： 清洁验证实际就是对清洗标准操作规程的验证，通过验证建立合适的设备清洁标准操作规程。清洁验证的目的足证明所采用的清洁方法确能避免产品的交又污染，微生物污染以及清洁后残留的污染，使之达到可接受限度标准。 1、清洁验证的步骤 1．1列出待进行清洁验证的设备所生产的一组产品。 1．2选择参照产品。在所生产的一组产品中，选择最难清洁(即溶解度最小)的产品作参照产品。相对于辅料而言，活性成分的残留物对下批产品的质量，疗效和安全性有更大的威胁，通常将残留物中的活性成分确定为最难清洁物质。 1．3选择设备最难清洗部位和取样点。凡是死角、清洁剂不易接触的部位——如带密封垫圈的管道连接处，压力、流速迅速变化的部位如有歧管或岔管处，管径由小变大处，容易吸附残留物的部位如内表面不光滑处等，均应视为最难清洗部位。取样点应包括各类最难清洗部位。 1．4选择最不利清洗条件的参数 A=一组产品中最小NOEL=活性成分最小LAD／40（μｇ/60kg体重） 其中：NOEL—活性成分的无显著影响值； LAD—每60kg体重最小有效剂量；
40(即4×10)—总体安全系数； B—一组产品中最大口服日剂量(m1／g或mｇ/日) C—一组产品中最小批量(mg或m1) D—棉签取样面积(25cm2／每个棉签)； E—设备内表面积(或与物料直接接触的总面积) (cm2) F—取样有效性(一般取50％，即假定棉签所取样品有50％的量被洗脱出来)； 共5页 第2页 G—冲洗溶剂的体积(m1)。 1．5化学验证及可接受标准限度。清洗效果的最终评价根据是产品活性成分即主药及洗涤剂的残留量、微生物限度。目前，企业界普遍接受的限度标准基于以下原则： (1)生物活性限度：任何产品不能受到前一品种带来的超过其0．001的日剂量的污染； (2)分析方法客观能达到的能力：污染不能超过10PPm。 (3)微生物限度：视取样方法不同而异。棉签法取样可接受标准≤50CFU/棉签，最终冲洗水取样可接受标准≤25CFU／ml。 (4)以目检为依据的限度：不得有可见的残留物，假定为4μg/cm2(100μg/4in2)，且不得有残留气味。 1．5．1 所选择的参照产品生产结束后，按规定的清洁程序清洗设备，目检无可见残留物或残留气味． I．5．2 最难清洗部位棉签法取样。 目的：评价活性成分可能的残留物浓度，取样前棉签要在最合适的溶剂中润湿。 检验方法：HPLC或效果类似的方法。 可接受标准：每一棉签最大允许残留量为 B A×E C×D ×F(ug/棉签) 注意：A值选择有两种情况 第一：当活性物质效力较低,A=最小活性物质浓度×0.001; 第二：当活性物质效力较强,A=最小NOEL值。 1．5．3 冲洗溶剂取样。 目的：评价活性成分在整个设备内表面(或与物料 所接触部位)的潜在残留量，应采用对活性成分溶解效果好且对设备及人员较
xxxxxxxxxxxxxxxxxxxxxxxx 安全生产标准化评审 程序文件 HBYS-AB-B-2015
xxxxxxxxxxxxxxxxxxxxxxxx 2016年5月25日 2016-5-25发布2016-5-25实施
目录 第一章保证公正性程序HBYS-AB-B?01—2015 (1) 第二章保护客户机密及所有权的程序 (2) HBYS-AB-B?02—2015 (2) 第三章不符合工作控制的程序HBYS-AB-B?03—2015 (4) 第四章预防/纠正措施控制程序HBYS-AB-B?04—2015 (6) 第五章人员培训程序HBYS-AB-B?05—2015 (9) 第六章获取法律法规和技术标准控制程序 (11) HBYS-AB-B?0６—2015 (11) 第七章安全生产标准化评审程序HBYS-AB-B?0７—2015 (13) 第八章评审审核程序HBYS-AB-B?0８—2015 (20) 第九章安全生产标准化工作程序HBYS-AB-B?09—2015 (22)
第一章保证公正性程序HBYS-AB-B?01—2015 1.1 目的 确保本公司安全生产标准化评审人员保证现场评审工作的公正性及诚实性。 1.2 适用范围 适用于对本公司所有评审员及评审专家公正行为的控制。 1.3 职责 1.3.1 总经理负责对工作人员不良行为的处理。 1.3.2 质量负责人规范评审人员的工作行为。 1.4 程序 1.4.1 工作人员公正行为的教育与控制 （1）应教育全体评审人员抵制来自于上级部门、关系单位及受审企业的影响和压力，确保评审工作的质量。 （2）综合部在制定《XX年度培训计划》时，应充分考虑对全体人员的公正行为教育，加强对人员公正性教育的培训。 （3）质量负责人依据《XX年度培训计划》对本单位评审人员进行公正教育和相关法律、法规的培训。 （4）保证本公司评审人员不参与与工作相关的商业活动，保证本部门工作人员不因财务问题而影响工作的公正性和诚实性。 （5）监督人员应履行职责，监督各工作人员的技术操作能力和工作质量，如发现违规人员，应及时上报处理。 1.4.2 工作人员不良行为的处理 （1）质量负责人负责对本公司评审人员不良行为的调查。当问题严重时，应由公司组织专门人员进行调查。 （2）如评审人员存在不良行为时，应立即停止其工作或调整工作岗位，上报总经理予以处理。如发现由于其不良行为对客户造成了损失，应及时与客户进行沟通，尽量挽回对客户的影响。 （3）综合部负责不良行为处理的记录和记录存档。
中国核工业建设集团公司安全标准 安全生产标准化达标标准及评分细则 （2013版） Standards and Scoring Rules for Safety Production Standardization (Tentative) 2013-01-15发布2013-01-15实施 中国核工业建设集团公司发布
目录 前言................................................................ 错误!未定义书签。一总则............................................................... 错误!未定义书签。二规范性引用文件..................................................... 错误!未定义书签。三术语和定义......................................................... 错误!未定义书签。四考评工作要求....................................................... 错误!未定义书签。 （一）考评机构..................................................... 错误!未定义书签。 （二）考评内容..................................................... 错误!未定义书签。 （三）考评办法..................................................... 错误!未定义书签。 （四）评分导则..................................................... 错误!未定义书签。 （五）考核评级..................................................... 错误!未定义书签。 （六）考评程序..................................................... 错误!未定义书签。五监督检查........................................................... 错误!未定义书签。六附则............................................................... 错误!未定义书签。七安全生产标准化达标标准及评分细则................................... 错误!未定义书签。 （一）安全管理标准化达标标准及评分细则 ............................. 错误!未定义书签。 （二）安全绩效标准化达标标准及评分细则 ............................. 错误!未定义书签。 （三）现场标准化达标标准及评分细则 ................................. 错误!未定义书签。
(1) 清洁验证的一般要求 清洁验证是通过文件证明清洁程序有效性的活动，它的目的是确保产品不会受到来自于同一设备上生产的其他产品的残留物、清洁剂以及微生物污染。 为了证明清洁程序的有效性，在清洁验证中应至少执行连续三个成功的清洁循环。 对于专用设备，清洁验证可以不必对活性成分进行考察，但必须考虑清洁剂残留以及潜在的微生物污染等因素，对于一些特殊的产品，还应考査降解产物。 对于没有与药物成分接触的设备（如加工辅料用的流化床或包衣片所使用的包装设备），清洁验证可以不必对活性成分进行考察，但必须考虑清洁剂残留及微生物污染等因素。 清洁验证中需对下列放置时间进行考察，进而确定常规生产中设备的放置时间： ? 设备最后一次使用与清洁之间的最大时间间隔（“待清洁放置时间”）； ? 设备清洁后至下一次使用的最大时间间隔（“清洁后放置时间”）。 (2) 清洁验证的前提条件 进行清洁验证的前提条件是: ? 清洁程序已批准，其中包括关键清洁程序的参数范围； ? 完成风险评估（对于关键操作、设备、物料包括活性成分、中间体、试剂、辅 料、清洁剂、以及其他可能影响到清洁效果的参数）； ? 分析方法经过验证； ? 取样方法已经批准，其中包括取样规程和取样点； ? 验证方案已经批准，其中包括接受标准（根据不同设备制定）。 (3) 测试项目 清洁验证中涉及的测试项目应根据产品的类型通过风险分析而定，通常需考虑以下 内容： 參目测检查； ? 活性成分残留； ? 清洁剂残留； ? 微生物污染； ? 难清洁并可能对后续产品造成不良影响的辅料（如色素或香料）。 ( 4 ) 取样 清洁验证中应用的取样方法应详细规定并且经过批准，选择取样方法时应考虑残留物和生产设备的特性。 3 产品质量实现的要素 化学成分残留取样：
安全标准化评定程 序
金属非金属矿山安全标准化评定程序 吉林宝华安全评价有限公司 10月
目录 1安全标准化评定依据 .......................................... 错误!未定义书签。2安全标准化等级评定原则 .................................. 错误!未定义书签。3安全标准化考评条件 .......................................... 错误!未定义书签。4安全标准化评定程序 .......................................... 错误!未定义书签。 5 考评前的准备工作 .............................................. 错误!未定义书签。6现场考核工作程序和要求 .................................. 错误!未定义书签。
1安全标准化评定依据 金属非金属矿山企业安全标准化采用的标准为: AQ .1- 金属非金属矿山安全标准化规范 AQ .2- 金属非金属矿山安全标准化规范地下矿山实施指南 AQ .3- 金属非金属矿山安全标准化规范露天矿山实施指南 AQ .4- 金属非金属矿山安全标准化规范尾矿库实施指南 AQ .5- 金属非金属矿山安全标准化规范小型露天采石场实施指南 安监总厅管[ ]70号国家安全监督总局办公厅关于印发金属非金属矿山安全标准化评分办法的通知 金属非金属地下矿山安全标准化评分办法 金属非金属露天矿山安全标准化评分办法 尾矿库安全标准化评分办法 小型露天采石场安全标准化评分办法 2安全标准化等级评定原则 2.1安全标准化评定指标包括标准化得分、百万工时伤害率和百万工时死亡率。
***-AB-CX —2017 A/0 ****** 有限公司 安全标准化程序文件 版次：第A版 修订状态：第0次 受控状态：受控 编制：_____________________ 审核：_____________________ 批准：_____________________ 2017年X月X日发布2017 年X月X日实施
安全环保部发布 目录 （手册□、程序文件□、制度或作业文件口）制订/修订审定 (3) 前言 (4) 1 安全标准化文件与资料控制程序5 2 标准化记录控制程序15
、八前言
安全标准化程序文件依据《企业安全生产标准化基本规范》 (GB/T33000-2016)、《工贸企业安全生产标准化建设实施指南》和《冶金等工贸 企业安全生产标准化基本规范评分细则》编制。 安全标准化程序文件共计2 个，规定了本公司安全标准化系统管理方面的要求，规范了安全标准化系统主要核心内容及相关记录。各单位、科室对在使用过程中的问题，请及时反馈，以便更好的指导工作，并作为下一步修订时的参考资料。 安全标准化程序文件由公司安全环保部负责组织编写，在管理制度制定、修改、评审过程中吸收员工代表参与，由安全标准化系统管理者代表审核，最后由总经理批准发布。 安全标准化程序文件的解释权归公司安全环保部。
安全标准化文件与资料控制程序 1. 目的 为了对我公司安全标准化系统文件的识别、编写、审批、发布、发放、修改、回收和评审等过程进行有效控制，以确保在安全标准化系统运行中各科室、单位都可获得并使用适用的文件有关版本，制定本程序。 2. 范围 本程序适用于对公司安全标准化系统所要求的文件进行控制。 3. 职责 3.1安全环保部是安全标准化文件控制的归口管理部门，负责分工的安全标准化系统文件的识别、编制、审核，负责安全标准化系统文件的标识、发放、保管、更改、回收、作废管理。 3.2安全环保部负责分管文件的编制、审核，并负责外来文件适用性的审核和控制。 3.3分管安全副总经理审批安全标准化系统有关文件及安全标准化手册等。 3.4总经理批准和发布安全标准化系统有关文件及安全标准化手册等。 3.5各科室、单位负责本部门与安全标准化系统有关的文件的编制、审核和本部门所有文件的管理和控制。 4. 文件控制流程
安全标准化评审标准要素清单 A级要素否决项 1. 二级企业未初步形成安全文化体系，扣100分（A级要素否决项）。 2. 一级企业未有效运行安全文化体系，扣100分（A级要素否决项）。 3. 未建立安全生产责任制，扣100分（A级要素否决项）； 4.二级企业建立了健全的安全生产责任制和安全生产规章制度体系，并能够持续改进。不符合，扣100分（A级要素否决项）。 5.未设置安委会、安全生产管理部门或配备专职安全管理人员，扣100分（A 级要素否决项）。 6.二级企业本要素若失分，或存在重大隐患，扣100分（A级要素否决项）。 7.一级企业未建立安全预警预报体系，扣100分（A级要素否决项）。 8.未建立重大危险源管理制度，或未辨识、确定重大危险源，扣100分（A级要素否决项）。 9.重大危险源有重大事故隐患，且未采取安全防范措施的，扣100分，（A级要素否决项）。 10. 3.5 重大危险源（20分）若失分，扣100分（A级要素否决项）。 11. 未制定动火作业管理制度或进入受限空间管理制度，扣100分（A级要素否决项）； 12. 未按国家安全监管总局令第8号要求进行设计审查、安全条件论证和竣工验收的，扣100分（A级要素否决项）。 13. 使用无资质或资质不符合规定的设计、施工、监理单位，扣100分（A级要素否决项）。
14.1.采用国家明令淘汰的工艺、技术、设备、材料，扣100分（A级要素否决项）； 2.国内首次采用的化工工艺未经论证的，扣100分（A级要素否决项）；15. 二级企业化工生产装置未设置自动化控制系统，或涉及危险化工工艺和重点监管危险化学品的化工生产装置未根据风险状况设置安全联锁或紧急停车系统等，扣100分（A级要素否决项）。 16. 一级企业涉及危险化工工艺的化工装置未设置安全仪表系统，或未建立安全仪表系统功能安全管理体系，扣100分（A级要素否决项）。 17. 一级企业涉及危险化工工艺和重点监管危险化学品的化工生产装置未进行过危险与可操作性分析（HAZOP），或未定期应用先进的工艺（过程）安全分析技术开展工艺（过程）安全分析，扣100分（A级要素否决项）。 18. 未实施危险性作业许可管理，扣100分（A级要素否决项）。 19. 二级企业动火作业、进入受限空间作业及吊装作业管理制度、作业票证及作业现场评审不失分。若失分，扣100分（A级要素否决项）。 20.未建立完善的作业场所职业危害控制管理制度与检测制度，或未有效实施，或作业场所职业危害未得到有效控制，扣100分（A级要素否决项）。 21.存在事故瞒报、谎报、拖延不报现象的，扣100分(A级要素否决项)。 22.二级企业未将承包商事故纳入本企业事故管理，扣100分（A级要素否决项）。 23.未进行自评，扣100分（A级要素否决项）。 24.未满足本地区要求，A级要素否决项 B级要素否决项 1.未明确专门部门定期识别和获取，扣50分（B级要素否决项）。
副本编号： ***制药厂 颁发部门： 技术质量科题目： 设备清洁验证中的取样方法 共6页 第1页 文件编码：SOP―A7―005版本号： 01 替代：起草： 部门审查：QA审查：批准：执行日期： 2008-01-25 变更记载： 修订号：批准： 执行日期： 变更原因及目的： 文件副本分发明细 质监部01 药检中心02 提取车间03 正本：技术质量科副本编号：01-03
一.目的 建立设备清洁验证中的取样方法，以规范设备清洁验证中的残留物取样方法，确保所取的样品具有代表性和有效性，防止由于取样不当，而造成错误的验证结果。 二.范围 本标准适用于***分厂精烘包洁净区内原料药生产关键设备的清洁验证中的取样方法规定，包括：擦拭取样方法和最终淋洗水取样方法。 三.职责 1、洁净区设备清洗人员：应严格按设备清洁SOP规定，对设备进行清洁、记录； 2、药检中心取样人员：负责在设备清洁验证中，按本取样方法规定取样、记录； 3、药检中心主任：负责按本规程规定，确保其正确实施； 4、质量科、质监部：负责按本规程规定，进行监督管理。 四.程序 1、总则 1.1设备清洁验证中，需对设备清洁后进行残留物质取样、检测，必须确定取样位置。取样位置的确定原则是设备上的最难清洁部位作为取样点，目的是保证取样在设备清洁后的最差部位上进行； 1.2取残留物样的取样方法有最终淋洗水取样和擦拭取样二种方法，各自适用于不同设备的取样，具体要求如下； 1.2.1最终淋洗水取样：为大面积取样方法，其优点是取样面大，对不便拆卸或不宜经常拆卸的设备也能取样。因此其适用于擦拭取样不易接触到的表面，尤其适用于设备表面平坦、管道多且长的液体和浆料生产设备。 1.2.2擦拭取样优点是能对最难清洁部位直接取样，通过考察有代表性的最难清洁部位的残留物水平评价整套生产设备的清洁状况。通过选择适当的擦拭溶剂、擦拭工具和擦拭方法，可将清洗过程中未溶解的，已“干结”在设备表面或溶解度很小的物质擦拭下来，能有效弥补淋洗取样的缺点。 1.3不管是何种取样方法，在对化学残留物和微生物残留物取样时，应先取微生物残留样，后取化学残留物样，以防止后取微生物样时，样品受到污染； 1.4取样方法应经过验证，以证明其适用性。取样方法的验证实际上是对溶剂或和药签的选择、取样人员操作、残留物转移到溶剂或和药签、样品溶出（萃取）过程全面考察； 1.5设备清洁验证中取样，应从设备最终每一次淋洗结束后进行，以确定设备的淋洗次数。但是，在每一次淋洗时，如残留物检测不合格，不能进行重复取样，直至检测合格，这表明淋洗次数不足够。 2、最难清洁部位和取样点 2.1根据取样点确定原则，确定最难清洁部位为取样点，具体要求如下；